Execution & Publishing
Running, publishing, and versioning workflows.
Building a flow and putting it live are two separate steps. You validate a flow while editing, and publish it when it's ready to handle real traffic.
Testing a flow before you publish
Test in the editor runs the saved version you have open, published or not, as a browser voice call, a run with starting variables, or a first SMS or chat message, and shows its path on the canvas. See Test a Workflow. Without it, a flow executes only when a real conversation reaches it, so testing means publishing to a number you can call, or a workflow that isn't in front of customers yet.
The editor also gives you:
- File → Verify Flow checks the flow against the rules below without executing anything. It is the fastest way to catch an unset initiator or an empty required field.
- Test on an Integration, SharpenDB, or Invoke Lambda node sends that one node's configured request and shows you the response, so you can confirm a query or an endpoint before the flow depends on it. It runs the node on its own, not the flow around it.
After a real conversation, View in Flow in Insights → Call Logs replays it on the canvas, step by step, against the workflow version that actually ran.
Validation
A flow must be valid before it can be published. The most common requirements:
- An initiator node is set (see Flow Basics).
- Every required field on every node is filled.
- Fields required in combination are complete — a Play Message node set up for text-to-speech needs content, a language, and a voice, even though each of those is optional on its own (a node playing an audio file needs none of them).
Fix any validation issues surfaced in the editor, then publish. File → Verify Flow runs the same checks on demand, so you can see what's outstanding before you're ready to publish.
Publishing re-runs this validation and is refused if anything fails, so a flow can't go live in a state the editor would have flagged. This applies to publishing through the API as well as the editor. Warnings don't block a publish — only errors do.
Publishing
When your flow is ready, publish it to make it live.
Publishing saves and promotes the current version to production. Active calls routed to the workflow begin using the published version immediately.
Because publishing takes effect right away, treat it as a production deploy: run the flow first, and prefer publishing changes to high-traffic workflows during a low-traffic window.
Versions
Each publish creates a new version. Opening a workflow from the workflows list takes you to its published version; use File → Manage Versions to view the version history, open a draft, or roll back to a previous version if a change causes problems.
Rolling back re-promotes an earlier version to production, so it's the fast way to undo a bad publish without re-editing the flow. Versioning also gives you a record of what changed and when.