Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.dialai.ca/llms.txt

Use this file to discover all available pages before exploring further.

Testing a flow before you ship it is the difference between an agent that works and an agent that drifts. The platform has three tools for this, in roughly increasing order of effort:
  1. Chat sandbox — a one-off interactive conversation, useful for quick “does this work?” checks while editing.
  2. Test Platform — emulate a specific channel (Voice, SMS, Web, Email) to verify channel-specific behavior.
  3. Test Scenarios — recorded conversations with assertions, replayable across flow versions to catch regressions.
This page covers all three.

​
Chat sandbox

The fastest way to talk to the flow you’re editing.
1

Open the chat sandbox

From the flow editor, click Chat (or go to /chat-test/{flowId}).
2

Send a message

Type as if you were the customer. The agent responds using the current draft of the flow.
3

Inspect what happened

The transcript shows function calls, state transitions, and the agent’s thought process alongside each turn. Use this to confirm the right functions are firing on the right inputs.
The sandbox always runs against the current draft, so any edit you save is immediately reflected on the next message. No need to publish.

​
Test Platform

The chat sandbox runs in a neutral text mode. Real conversations happen on specific channels — voice has different latencies and phonetic considerations than SMS; email is async and quote-aware. Test Platform runs the same draft flow but emulates a specific channel.
1

Open Test Platform

From the Flows page, click the three-dot menu on the flow card and select Test Platform.
2

Pick a channel

Voice, SMS, Web, or Email. Each applies the platform-specific behavior the runtime would apply on a live conversation.
3

Run through scenarios

Type messages as the customer. The agent responds in the chosen channel’s style — voice-style speech for Voice, short messages for SMS, formatted body text for Email.

​
Channel-specific things to watch

ChannelWatch for
VoiceThe agent spells back names digit-by-digit / letter-by-letter when needed; numbers are read naturally (twenty-two, not 2-2).
SMSMessages are short. Long structured responses get awkward on a phone screen.
WebFormatting renders (Markdown, lists, links).
EmailQuotes and threading work; the agent’s tone reads as written, not spoken.
To input spaced/spelled-out characters in voice tests, type each letter separated by spaces — B r i a n — and the runtime will treat it as a spelled name.

​
Test Scenarios

The chat sandbox and Test Platform are interactive — good for exploring, bad for catching regressions. Test Scenarios are recorded conversations with assertions: you walk through a flow once, save the scenario, and the platform can replay it against any future flow version to confirm behavior is stable.

​
Creating a scenario

1

Open Test Scenarios

On the flow editor, open the Test Scenarios panel.
2

Record a conversation

Click New scenario, walk through a representative conversation in the sandbox. Each turn is captured along with the agent’s response, function calls, and state transitions.
3

Add assertions

On each turn, mark which assertions matter: a specific state was reached, a specific function was called, a specific event was emitted, a specific tag was set, the agent’s reply contained certain phrasing.
4

Categorize and save

Assign the scenario to a category (e.g., “Happy path”, “Edge cases”, “Compliance”). Save.

​
Running scenarios

The Test Scenarios panel lists every saved scenario. Click Run on one to replay it; click Run all to replay the entire category. Each run shows pass/fail per assertion alongside the full replay transcript.

​
Versioned results

Test results are tracked per flow version. When you publish a new version of a flow, run all scenarios — the platform records the result against that version. The history view shows which scenarios pass against which versions, making it easy to see when a regression was introduced and against which change. This is the safety net for editing a flow that’s already live. As long as your scenarios cover the conversations you care about, you can edit confidently — failing assertions will catch breakage before it reaches customers.

​
What to test before publishing

A minimal test plan for any flow heading to production:
  • Happy path for every primary intent your flow handles.
  • Disambiguation — what happens when a function returns multiple matches or no matches.
  • Out-of-scope requests — the customer asks for something this flow can’t do; does the agent transfer or escalate gracefully?
  • Emergencies if your domain has them — fire, gas leak, medical, threats of harm. The agent must route correctly.
  • Channel-specific quirks — at minimum a smoke test on each channel the flow will run on.
  • Language fallback if the flow is single-language but customers may try another.
Convert each into a Test Scenario so future edits can’t regress them silently.

Building your first flow

Where testing fits in the build process.

Designing thoughts

Most flow bugs are thought bugs — fix them here.

Flow configuration

Configure call review criteria that complement scenario testing.