The simulator

The simulator runs a recipe against the real bot runtime so you can test flows without sending actual WhatsApp messages or paying per-message fees. It executes the same kernel as production — the difference is that outbound messages are rendered in the simulator panel instead of being shipped through the channel adapter.

Opening the simulator

In the recipe canvas, click the ▶ Test button in the editor toolbar (next to Save). The simulator opens as a right-docked panel beside the canvas; it does not navigate away from the editor.

The panel has three regions:

• Variables at the top — every variable currently in scope, with its value.
• Chat thread in the middle — bot outputs as left-aligned bubbles, your typed inputs as right-aligned bubbles, and status pills like “Simulation started” and “Session ended”.
• Footer at the bottom — Reset, language toggle, Persist checkbox, and a saved-session ID once the run has been persisted.

Sending a test message

Type into the composer at the bottom of the chat thread and press Enter (or click Send). The runtime treats your input as a fresh inbound message: triggers evaluate, a flow session is created, and outbound messages render in the panel as the recipe advances. Each variable assignment is reflected immediately in the Variables panel.

Validation-only mode

If the recipe has unresolved validation blockers (missing required configuration, dangling edges, broken sub-flow references, etc.), the kernel refuses to run and the panel switches to validation-only mode. An amber banner appears at the top of the panel and the blocker list is shown — you cannot send messages until the blockers are resolved. Warnings (non-blocking issues) are listed alongside but do not gate the run.

Reset

The Reset button discards the current test session, clears the chat thread, and zeroes out the Variables panel. Useful for testing edge cases (“what happens if the customer types nothing”, “what does the Arabic branch look like”) without redeploying.

Switching language

The footer’s EN / عربي toggle controls which language the simulated contact appears to be using. Bot messages render in the matching localised body, and language-scoped triggers behave as they would on a real conversation in that language. The toggle does not change the language of the editor itself.

Persisting a run

Tick the Persist checkbox in the footer to save the simulation run. The session ID appears next to the checkbox once it’s been written. Persisted runs show up on the recipe’s Simulator runs page (under the recipe detail) so you can refer back to them later or share a link with a colleague. Leave the checkbox off for throw-away exploration — only runs saved with Persist on appear there.

Only the newest 20 persisted runs per recipe are kept (this cap is configurable by your administrator). When you persist a new run beyond that limit, the oldest run is automatically removed along with its full footprint — its step trace and the simulated conversation. A 90-day age limit also applies as a backstop, so a run is removed once it is either older than 90 days or pushed past the 20-run cap, whichever comes first. Export or note down anything you need to keep long-term.

Reviewing a saved run

Open the recipe’s Simulator runs page to browse every persisted run for that recipe. The left rail lists each run with its status, the time it started, the number of nodes it touched, its session ID, and its language. Click a run to open its detail view on the right.

Each run opens with a compact summary header — status, session ID, language, step count, duration, and the start time — followed by three tabs:

• Steps (the default) — the run laid out as an ordered list of step cards, one per node, in the true order they executed. Each card shows the node’s icon, its friendly name, its type, and a status check. Expand a card to see what that node Sent (the bot messages it produced), what it Captured (variables it set — any value classified as PHI or PII is masked), which branch it took (Next, Fallback, or Failed, shown as an arrow to the next node by name), and, on the final step, the run’s Outcome (for example “Closed by bot” or “Transferred to a human”).
• Variables — the final variable snapshot for the run, shown as JSON.
• Raw events — the underlying event-by-event list (node entered, branch taken, variable set, session started/ended, and so on) with timestamps, kept for power users who want the unsummarised trace.

The Steps tab is the place to start when you want to understand what the bot actually did; reach for Raw events only when you need the low-level detail. Older runs that were saved before per-step tracing existed open straight to the Variables tab and are labelled “validation only”.

What’s mocked vs real

Limits & gotchas

• The simulator runs against your draft recipe — to test the published version, publish first.
• Each simulator session always starts at the recipe’s Start node — there is no way to enter the flow at a specific downstream node.
• Real outbound integrations (API, Webhook, Agent) hit live systems. Point them at staging endpoints during recipe development.
• Sub-flow calls work — control follows the sub-flow exit ports as it would in production — but the sub-flow’s variable scope follows the standard rules described in Variables & expressions.