Start free

All nodes/Logic & Flow/Branching

Switch

Multi-way branching: an ordered list of conditions ({{ }}), each with its own output. The first condition that is true wins; if none is, the branch named in 'Default branch' ('default' unless changed) runs.

Switch▶
InputDefault

Type in the graph: switch

Exec

An error output can be enabled 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.

Entry
Switch▶
Template▶
Template▶
Template▶
Exit▶
  • Execute + Data
Press “Copy nodes”, open the editor and hit Ctrl+V on the canvas.

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 branch” 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 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

PortWirePayloadNotes
InputinputExecute + Dataexecute_data—

Outputs

PortWirePayloadNotes
DefaultdefaultExecute + Dataexecute_data—

Configuration

FieldTypeDefaultDescription
Casescasesarray—

Ordered list of condition→handle pairs; first truthy match wins

Default branchdefault_casestringdefault

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.

Ready-made examples using this node