Two ways to test
The workflow editor gives you two test modes, both from the top-right of the canvas.
| Mode | What it does | What it catches |
|---|---|---|
| Test on Chat | Opens a text simulator in the browser. You type, the Finn responds. Each node shows its inputs and outputs in real time. | Branch logic, variable wiring, unreachable nodes, parser mismatches |
| Test on Call | Calls your phone. Full end-to-end path through telephony and voice. | Everything Chat catches, plus voice, timing, interruptions, transfers |
Use Chat while building. It is faster, and the per-node input/output panel is the only place you can see which branch a Decision node actually took. Use Call before you launch anything to real callers, because Chat never exercises the voice stack or a Transfer Call action against a real number.
Save before you test. Autosave is off by default in the editor, and the test runs against the saved workflow, not the canvas in front of you. If your edit does not seem to take effect, that is usually why.
Test the branches, not the flow
The happy path is the path you already designed. It is almost always fine. The failures live in the branches you did not walk.
Work from your Decision nodes backwards. For each one, list the conditions it can evaluate and run one test per outcome. A Decision on {{state.severity}} with rules for >= 8, 4-7, and < 4 needs three runs, not one. Say the value out loud in the Chat simulator the way a caller would say it, not the way your condition is written.
Then walk every End node. If you built four End nodes for four outcomes and only three ever fire in testing, the fourth is either unreachable or reachable only through a case you have not thought of. Both are worth finding now, since each End node becomes a separate category in your analytics and a dead one will quietly report zero forever.
What actually breaks
These are the failures that survive a casual test and show up on real calls.
Answers that do not parse. Your Ask node expects a date, the caller says "the fourteenth, I think." The parser fails and the flow stalls or re-asks in a loop. Test each Ask node with a deliberately messy answer, not just the clean one. If it fails, add a fallback edge or switch the node to AI-evaluated so the model can interpret paraphrasing. Every Ask node should have a fallback edge before you launch. See workflow-nodes for the node options.
Variable name drift. A Say node references {{state.severity}} while the Ask node saved to severity_score. Nothing errors. The caller hears the literal {{state.severity}} in the transcript. Chat mode surfaces this immediately because the rendered text appears in the response. Check every Say node that interpolates, and every Action node parameter. More on this in workflow-variables.
Loops back into an Ask node. An edge that returns to a question the caller already answered makes the Finn ask the same thing twice. Trace any edge that points backwards in the flow and confirm it lands somewhere that moves the conversation forward.
Actions that only fail live. Book Calendar, Update CRM, Send SMS, and Webhook nodes hit real systems. A Chat test will run them. Confirm the side effect landed on the other side, not just that the node returned. Use a throwaway calendar or CRM record while testing so you are not writing junk to production data. Transfer Call is the one to verify on a real call, since the handoff behavior depends on telephony.
Nodes with red borders. The editor marks invalid nodes with a red border, and the Save button stays grayed out until they are resolved. If Save will not fire, look for the red node before looking anywhere else.
Iterate in small pieces
You do not have to finish the workflow before you can test it. Build a chunk, test it, build the next chunk. A workflow tested only once at the end gives you a list of failures with no idea which edit caused them.
If the editor starts lagging, you are probably past roughly 30 nodes. That is a structural signal as much as a performance one, since a flow that size is also hard to test exhaustively. Splitting it makes both problems smaller.
After a bad test
Every save creates a new version. If a test that used to pass now fails, open Edit Workflow → History, compare against the last version you trusted, and Restore if needed. A restored version becomes the current version. Active deployments keep running on the version they launched against, so a bad save does not affect calls already in flight. See workflow-versioning.
For symptoms that are not workflow-specific (silent test calls, missing analytics, unregistered numbers), start at troubleshooting.