Connections
Join nodes with connections, understand which handles each node has, and route failures and alternative outcomes to their own paths.
A connection is the line between two nodes. It decides which node runs next, and it passes the first node's result to the second as input. State travels with the whole run regardless of connections, so any node can read state.* values set earlier on its path.
Make a connection
Start from an output handle
Hover over a node until its handles show. Output handles sit on the side the flow leaves from; the input handle is on the opposite side.
Drag to the next node
Drag from the output handle and drop onto the target node's input handle. The line appears when the connection is valid.
Or drop on empty canvas
Release the drag over empty canvas instead and a placeholder node appears with Add Node. Search for a node and press Enter to insert it already connected.
To remove a connection, select it and press Delete or Backspace. To point it somewhere else, delete it and draw a new one.
Handles on each node
Most nodes have one input and one output. Nodes that can finish in more than one way show one output handle per outcome, each with a label beside it so you can tell them apart.
| Node | Output handles |
|---|---|
| Menu | One per option, labelled with the option |
| Router | One per condition, labelled with its value, plus default |
| Filter | true, and false for runs that fail the condition. Only voice projects follow false; elsewhere a failed condition stops the run. |
| API, Integration | success and failure while Failure path is on; a single output when it is off |
| Form | submit, cancel and failure |
| Approval | approved and rejected |
| Loop | each item (the loop body) and done |
| Parallel | branch 1, branch 2 and so on, plus done |
| Voice nodes such as Menu (voice) and Transfer | One per key or outcome, including paths such as an unrecognised key, no input or no answer |
Trigger nodes such as Trigger, Incoming Call and the automation triggers have no input handle, because nothing runs before them.
Failure paths
An API or Integration node can fail: the service is down, times out, or returns an error. With Failure path switched on (the default), the node gets a failure handle: "Route to failure output on non-2xx responses, timeouts, or network errors." Connect it to whatever should happen instead, such as an apology message, a retry later, or a handoff to a person.
If you switch Failure path off, the node has a single output and a failed call continues down it like a successful one, so the next node has to check the result itself.
See Error handling for retries and the other ways a flow can recover.
Long connections
A connection that crosses half the canvas is hard to follow. Select it and choose Make jump link: the line is replaced by two chips, one at each end, that jump to the other end when clicked. Restore edge turns it back into a line. The connection itself is unchanged, so the flow runs the same either way.
Loops back to an earlier node
You can connect a node back to one earlier in the flow, for example from an Error node back to the menu that asked for input. Make sure every loop has a way out, such as a valid answer or a retry limit, so a user cannot get stuck.
Check your connections
- Every node is reachable. A node with no incoming connection never runs, and publishing reports it.
- Every branch goes somewhere. An unconnected option, condition or failure handle ends the run at that point.
- Router has a default, and it is last. Unmatched input then has somewhere to go. In USSD projects, publishing fails if any Router condition is left unconnected.
- Loops have an exit.
Troubleshooting
Related
Build a flow
Plan a flow, place and connect nodes, store and reuse values, and test it, with the differences between USSD, chatbot, voice and automation projects.
Variables and templating
Read state, the previous node's output and secrets in any field with double-brace templates, and use the variable picker to insert them.