🇬🇧 EN

🔀 Switch

Routes the workflow to one of several named branches based on the value of an expression. Works like a switch/case statement — each possible value gets its own path, with a default branch for anything that does not match.

Category: Flow Control · Type identifier: switch

Overview

When you need to send a workflow down more than two paths — not just true or false — the Switch node is the right tool. You define a single expression to evaluate (usually a variable from a previous step), then list the specific values you want to handle. Each value becomes a separate branch. Any value not listed is captured by the default branch.

This is useful whenever a piece of data can be one of a known set of values and each value requires different follow-on actions. Classic examples include order statuses, notification types, user roles, or response codes.

In graph mode, each case value creates a dedicated output port on the Switch node. Draw an edge from each port to the first node of the corresponding branch. The default port catches all unmatched values.

In linear mode, subsequent steps are tagged with a case label. Only steps whose label matches the evaluated case will execute. Steps tagged default run when no case matched.

Configuration

Field	Status	Description
Expression	Required	The value to test. Can be a static value or a variable reference, e.g. `{{ order.output.status }}`. The expression is evaluated and its result compared against each case.
Cases	Required	An array of case values. Each entry creates one named branch. A default branch is always present and catches anything that does not match a defined case.

Output Data

The Switch node exposes the following output variables in subsequent steps:

Variable	Type	Description
`matched_case`	string	The case label that was matched, e.g. `"approved"`. If nothing matched, the value is `"default"`.
`expression_value`	mixed	The raw value that was evaluated — useful for logging or downstream display.

// Access switch outputs in later steps {{ switch_step.output.matched_case }} {{ switch_step.output.expression_value }}

Example Usage

Route an order by status

An e-commerce workflow receives an order object. Depending on the status field, it must send different emails, update different records, and call different downstream services.

Add a Switch node. Set the Expression to:
{{ order.output.status }}
Add four cases: pending, approved, rejected, and keep the automatic default branch.
In graph mode: connect the pending port to a "Send confirmation email" node, the approved port to a "Fulfil order" sub-graph, the rejected port to a "Notify customer of rejection" node, and the default port to a Stop node with a warning message.
Each branch completes independently — only one branch runs per execution. There is no merge point after a Switch unless you explicitly route all branches back to the same downstream node in graph mode.

Tips & Notes

Case matching is exact. Comparison is case-sensitive and type-aware. The string "Approved" does not match a case labelled approved. Normalise your data upstream if needed (e.g. with a Set Variable node using a lowercase transformation).
Always connect the default branch. Data that does not match any case will route to default. If you leave it unconnected, those runs will end silently with no indication of what happened. Connect it to a Stop node or a logging step.
Variable expressions work too. The Expression field is not limited to plain variable paths. You can use any value that resolves to a comparable result, including values you have set with a Set Variable node.
Use Logic Gate for complex rules. If a branch requires more than a simple equality check — for example, "amount greater than 500 AND currency is USD" — place a Logic Gate node at the start of that branch rather than trying to encode the logic in the Switch configuration.

Related Nodes

Logic Gate — binary true/false branching using condition expressions.
Stop — terminate a branch with a specified status and message.
Parallel — run multiple named branches simultaneously rather than exclusively.