The Switch Node
Routes into more than two branches at once.
What it actually does
The If node is great for a single yes/no decision, but plenty of real workflows need to route based on more than two possibilities — by category, by status, by region, by type. Rather than chaining several If nodes together to approximate this, the Switch node handles it directly: in Rules mode, define a set of rules and each item gets routed to the specific output that matches, from several possible branches rather than just two.
There’s also an Expression mode, where instead of building rules in the UI you write an expression that returns the output number yourself — more flexible, but you’re on the hook for getting the logic right.
Each rule is essentially its own condition, similar to an If node’s, but instead of true/false, every rule gets its own named output. There’s also a Fallback Output for anything that doesn’t match any of your defined rules — worth always connecting this to something, even if it’s just a notification that an unexpected case came through, so nothing silently falls through the cracks.
Rules are evaluated in order, and by default an item goes to the first matching rule’s output only — worth knowing if you have rules that could theoretically overlap, since the order they’re listed in determines which one “wins.”
A worked example
A support ticket workflow needs to route tickets differently depending on their priority: “high,” “medium,” or “low.” A Switch node with one rule per priority level sends each ticket out of the output that matches, ready to be wired into its own downstream nodes — high-priority ones straight to an on-call alert, the rest into a normal queue.
Another common case: routing by country to apply region-specific logic — different tax handling, different currency formatting, different language for a notification — all from a single node rather than a chain of If/else nodes nested inside each other.
The mistake almost everyone makes first
Leaving the Fallback Output on its default setting. It’s easy to build a Switch node that correctly handles every case you thought of at the time, then have real-world data include something you didn’t anticipate — a new priority value, an unexpected category — which gets silently ignored instead of landing somewhere you can see it. Connecting the Fallback Output to at least a simple logging or notification step turns a silent failure into a visible one.