You can try a workflow as a draft, in a test session, without publishing it: customers keep getting the published version while you test the new one. If the workflow has an approval step, you can also simulate the manager’s answer (approved, rejected or expired) without opening a real request.
Think of it as a rehearsal on the real stage: no audience, but the lights and props are real. That last part matters.
Why don’t my edits reach customers straight away?
Because every edit is saved to a draft, and only publishing makes it live. updateWorkflow always writes to the draft and never changes what a live session runs. Sessions run whatever was published most recently. So you can edit as much as you like; nothing reaches a customer until someone publishes it (publishWorkflow).
The flip side: a draft that is never published does nothing for real sessions, and a forgotten publish is the most common cause of “it isn’t doing what I configured”.
How do I run the draft?
Send a message from a dedicated test session with testDraft: true on the dashboard’s sendMessage. That turn runs the agent’s current draft instead of its published version. The workflow does not need to have been published even once. Never set it on a real customer’s turn; it is for testing only.
How do I test an approval step?
Add draftApprovalOutcome (APPROVED, REJECTED or EXPIRED) alongside testDraft: true. The approval node completes at once and the workflow follows only that path. No request is created and no owner is notified. The saved decision carries "simulated": true, which also shows in the node’s trace. Without the option, a draft test stops at the approval node rather than opening a real request. The approval walkthrough shows the exact call.
Do the other steps run for real in a draft test?
Plan as if they do. The docs describe a simulated mode only for the approval node. They do not describe any step that calls another system (a tool, an action, a webhook) being skipped in a draft test. So before you test, point those steps at a test record or a test endpoint, not a live customer record.
How do I see what the test actually did?
Read the run record. workflowRuns(sessionId) lists the runs for your test session, and each run’s nodeTrace shows every step visited, in order, with its output. For tool, action and webhook steps it also shows the request actually sent. The observability guide covers every field.
Can I re-check old conversations after a change?
Yes, with a regression scenario. You save a completed real run as a baseline, then replay it against your current draft. Pass or fail compares the path (steps visited, branches taken, tool and action calls, final step), not the wording of the reply, and the result arrives a few seconds later. Use it before changing a step that routes messages, since a new model or prompt can quietly pick a different branch with no error.
A checklist before you publish
- Run the draft from a test session with
testDraft: true, using several real phrasings, not just your first example. - Try every approval outcome: approved, rejected and expired.
- Test the failure paths of steps that call other systems (a timeout, an error), not only the happy path.
- Read the
nodeTraceof each test run and confirm the path is the one you expect. - Keep your own copy of the graph (the nodes and edges you saved) before each publish. Earlier versions are not kept as snapshots you can fetch, so your copy is your rollback.
- Publish only then. A person on your team decides when it goes live; it never happens on its own.
Related reference docs
sendMessage: thetestDraftfieldpublishWorkflow: what publishing changes, and why an unpublished draft does nothing for real sessions- Draft tests for the approval node: simulating each outcome
- Regression scenarios: capture a run and replay it against your draft
- Observability and debugging: reading
nodeTrace
For the habits that make a workflow easier to test in the first place, read the workflow best practices.