Switch Step
The Switch step routes a run to one of several outputs. You define ordered routing cases: by default, the first matching case sends the run down its route. Enable Send to all matching branches when every match should run.
- Use it to
- Route a run to the first matching branch (or all matching branches when enabled)
- Find it
- Tools → Flow → Switch
- Cost
- Free (0 Step credits)
- Limits
- Named cases evaluated in order plus an optional Fallback branch
- Output
- Routes the run to the first matching Case (or Fallback when none match)
- Instead
- Conditions (when every matching route should run by default) or lookup pipe ({{ 1.tier | lookup:'{...}' }})
Use Switch for ordered case routing. For example, choose one support queue by checking cases in priority order. Conditions evaluates every regular route; Switch offers both first-match and all-matching routing. See Choosing a Flow Step for the difference between the three routing steps.
- runsDeal size is over 10,000Enterprise team
- skippedCountry is United KingdomUK team
- skippedFALLBACK — none matchedLog for review
Both cases match, but only the first one runs. Evaluation stops there, and the second is skipped.
Always assign the Fallback route. It routes executions when no explicit case matches. Without a fallback, unmatched runs halt at the Switch step without triggering downstream actions. Note that fallback requires at least one preceding case to evaluate against.
Setting it up
The panel uses the same rule builder as Conditions. For each case, pick the data, pick its type, pick an operator, and give it a value.
Add a routing case
Click Add routing case. New cases are added at the bottom, and since evaluation runs top to bottom, a new case is checked last. Add cases in priority order from most specific to broadest.
Build its rule
Pick the data to test, then choose its type: Text, Number, Yes/no, Record, List, or Date & Time. Then pick an operator from that type’s list. The full catalogue is on the Conditions page, and it is shared between the two steps.
Click Rule to add a second rule with AND or OR.
Point the case at a step
Under Then go to, choose where the run continues when this case wins. Wire the route as you build each case so the connection anchors the case on the canvas. If the target step does not exist yet, Then go to creates it for you.
Assign the fallback
Under Fallback, choose where everything that matched no case should go.
A case with a blank rule matches everything. This makes an empty case a useful catch-all when placed last (since first-match-wins turns it into a default). For other cases, ensure both the data property, operator, and comparison value are configured before testing.
Naming your outputs
Each case takes an optional output name, up to 50 characters. It is the Output 0 field at the top of the case. The name is echoed on the case’s result, so run history reads “Enterprise leads” rather than “case 2”.
Name outputs by the work each branch performs so execution records are easier to review.
How matching works
How matching works holds two settings that apply across the step:
| Setting | Default | What it does |
|---|---|---|
| Ignore capitalisation | Off | Text is case-sensitive by default (Active does not match active). Turn this on step-wide or override it on an individual rule. |
| Send to all matching branches | Off | By default, only the first matching case runs. Turn this on when cases act as independent labels (e.g. both high value and UK). |
The fallback route is skipped whenever at least one case matches. Imported automations may also expose Advanced import options; review and test representative inputs after importing.
Choosing a routing Mode
Native Switch steps always evaluate Rules (where each case’s rules decide the route). Automations imported in expression mode (mode: "expression") also display Mode and Output index, which select a branch by a zero-based number (0 for the first branch, 1 for the second, and so on).
What it passes on
Downstream steps read data from earlier steps as usual. The Switch step itself publishes the routing decision in the Execution log:
{
"mode": "rules",
"cases": [
{
"blocks": [
{
"conditions": [
{
"data": "standard",
"value": "enterprise",
"result": false,
"operator": "equals",
"conditionType": "string"
}
],
"blockSuccess": false
}
],
"matched": false,
"caseIndex": 0
}
]
}conditions[].result: Shows the exact values compared and whether each individual rule passed.blockSuccess: True when every AND rule inside that group passed.matched&caseIndex: Indicates whether the case matched and its zero-based position.
Examples to copy
Route support tickets by topic
| Case | Output name | Data | Type | Operator | Value |
|---|---|---|---|---|---|
| 1 | Billing | {{ 2.ret.topic }} | Text | is equal to | billing |
| 2 | Bugs | {{ 2.ret.topic }} | Text | is equal to | bug |
| Fallback | Not used | Not used | Not used | Not used | general triage |
Naming the outputs makes run history read "Billing" rather than "case 1".
- Run
- Test the Switch Step with input that matches Case 1, then re-test with input that matches no case.
- You should see
- The Execution log shows matched: true on Case 1 for the first run, and routes the second run down the Fallback branch.
What’s Next?
- Fire several routes at once, or use plain-language rules, with the Conditions Step.
- Fail loudly on the fallback with the Stop and Error step.
- Merge branches back into one path using the Do Nothing.