Routing: how a flow decides what happens next
A flow is not always a straight line. Real work branches on decisions, loops over lists, pauses for time, and sometimes waits for several signals before going on. Routario’s control-flow nodes handle all of these.
The four families of step
Section titled “The four families of step”It helps to see the whole picture first. Steps fall into four families:
| Family | What they do | Examples |
|---|---|---|
| Triggers | Start the run | Manual · Schedule · Webhook · Event |
| Modules | Do the actual work | Find records · Send email · Call an API |
| Flow management | Control execution order | Branch · Switch · For each · Merge · Wait · Checkpoint |
| Human | Pause for a person | Ask a person · Send pop-up |
This page is about the flow-management family — the nodes that decide which steps run, when, and how many times.
The control nodes
Section titled “The control nodes”A binary decision. It evaluates a condition and routes the run to the yes or no arm — exactly one runs. Use it for a single yes/no: “did the manager approve?”, “is the amount over the limit?”. For three or more outcomes, use Switch.
A value dispatch. It resolves an expression to a value and routes to the matching arm, falling through to a default. Use it when an upstream step produces something with several meaningful categories — a deal stage, a classification, an actor’s choice. A common source of that value is an AI step set to return one of a fixed list — see Branch on an AI decision.
A reconnect. Branch and Switch arms are exclusive (only one runs), so Merge simply continues whichever arm arrived and lets the shared downstream steps connect cleanly. Put one after a Branch/Switch whose arms feed common next steps.
Each arm’s steps keep their own labels, so a step after Merge can’t just say “the
value” — it has to name a label, and only one of them ran. See
Read a value from whichever branch ran
for first_defined() / last_defined(), which pick whichever candidate label
actually resolved.
A sequential loop: it runs its body once per item in a list, with the current item
in scope (e.g. {{ item }}). Strictly one at a time — if a body step pauses for a
person, the run waits there, then moves to the next item. An after path runs once
the list is done.
A single timed or event pause. The run parks in WAITING and resumes on its own:
- Duration —
"2h","3d","30m". - Until — an ISO timestamp or a template that resolves to one.
- At time of day —
"09:00": the next occurrence in the workspace timezone. - Event — a named platform event, with an optional timeout.
For several conditions at once, use Checkpoint.
The multi-condition form of Wait — a synchronization gate. The run parks until
all (or any) of a list of conditions are met; each can be an event, an
actor signal, or a timer. A timeout is mandatory, so an all-policy gate can’t hang
forever; on timeout the run continues (it doesn’t fail) and {{ <label>.reason }}
is "timed_out", so a downstream Branch can react. Its common use is joining
fire-and-continue Ask a person steps — each ask
dispatches and advances, and the Checkpoint waits for the answers.
At a glance
Section titled “At a glance”| Shape | Reach for it when |
|---|---|
| Branch | one binary decision (yes / no) |
| Switch | one value, three or more outcomes |
| Merge | rejoining exclusive arms |
| For each | iterating a list, one at a time |
| Wait | a single timed or event pause |
| Checkpoint | several conditions — all or any — with a timeout |
Where to go next
Section titled “Where to go next”- Asking a person — the ask step and fire-and-continue, which pairs with Checkpoint.
- Template variables — how
{{ label.field }}works inside conditions and fields. - Building an automation — a worked example using Branch, For each, and Ask a person together.