All nodes/Logic & Flow/Branching
Switch
Multi-way branching: evaluates an expression and selects one of several outputs by value (like switch/case). If the value matches none — the 'default' branch runs.
Type in the graph: switch
Exec
An error branch can be enabled (expose_error_output) to handle failures on their own path.
Ports can be split into separate execution and data handles.
Try it
Routing into three branches
Two cases read the incoming text, everything else falls through to the default branch.
- Execute + Data
Runs as pasted
When to use it
Reach for this node when there are more than two directions: a request type, the language
of a message, a service response code, a category from a classifier. For a two-way fork
if is enough — it is shorter and easier to read in the graph.
Despite the name, the node does not match one value against a set of options. It is a list
of “condition → output” pairs: conditions are checked top to bottom, the first truthy
one wins, and the rest of the list is never read. When none matches, the default branch
runs — its handle is set by the “Default Case Handle” field and is called default out of
the box.
How it works
Output ports come from the configuration: one port per case, plus the default port, which
always exists. Conditions are the same Jinja expressions as in if, with the same caveat:
write a compound condition or a text comparison entirely inside {{ }}, otherwise
substitution leaves you with a non-empty string, and a non-empty string is truthy.
The value passes straight through: the branch that fires carries whatever arrived on the
input. Downstream templates can read {{ nodes.<id>.output }} — that value — and
{{ nodes.<id>.branch }} — the handle of the branch that fired.
Configuration lives on the Conditions tab: the condition on the left, the handle id field on the right, an Add condition button and a Fallback handle row below. The neighbouring JSON tab shows the same cases as a list, which is the easier way to reorder them.
Common mistakes
- The order of conditions is part of the logic. A broad condition placed first hides every specific one under it. Start with the specific ones.
- Renaming a handle breaks the link. The port is drawn from the field value, so after an id edit the old port disappears together with its edge — draw the connection again.
- Two cases with the same handle give one port. The graph still runs, but it no longer shows which condition matched; different handling needs different ids.
- Do not name a case after the default branch — it collapses into the default port.
- An empty condition or an empty handle will not deploy: the validator names the case number.
- All branches into one exit is a normal shape. The node after the fork runs once, with the payload of the branch that fired; the validator warns about it so you do not expect the values of every branch at the same time.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Inputinput | Execute + Dataexecute_data | — |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Defaultdefault | Execute + Dataexecute_data | — |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Casescases | array | — | Ordered list of condition→handle pairs; first truthy match wins |
Default Case Handledefault_case | string | default | Fallback output handle when no condition matches |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.split_ports_in— Show separate execution and data input handles instead of one combined port.split_ports_out— Show separate execution and data output handles instead of one combined port.