n8n Switch Node:
multi-branch routing, real examples, and when IF won't cut it.

The IF node is fine for binary decisions. The moment you have three or more branches, you want Switch. If you've ever stacked IF nodes inside IF nodes trying to route a single field five different ways, I'm sorry. You needed this node two steps ago.

What the Switch node actually does (and why you probably needed it yesterday)

The Switch node routes incoming items to one of N outputs based on conditions you define. That's it. You configure as many outputs as you need, attach a condition to each one, and n8n sends each item to the first output whose condition it matches. Items that match nothing either get dropped or hit a fallback. Your choice, but you have to make it deliberately.

The key difference from the IF node is not subtle. IF gives you exactly two outputs: true and false. That's its entire design. Switch gives you as many outputs as you define. Each output is its own branch in the workflow. Downstream nodes connect to specific outputs and handle just the items that landed there.

Think of it like a train switching yard. One track comes in. The switch determines which of several outbound tracks the train takes. A wrong track means it ends up at the wrong destination. No track at all means it disappears, which is exactly what happens in n8n when you don't configure the fallback. More on that shortly.

In n8n's canvas, a Switch node looks like a standard node on the left (input) side, but with multiple connection ports on the right side, one per output you've configured. You drag wires from each port to whatever nodes should handle items for that branch. The number of visible ports grows as you add rules in the node editor.

Switch vs IF: the 30-second decision rule that stops spaghetti logic

This is not a "both are valid choices depending on your situation" answer. That kind of fence-sitting is useless when you're staring at a workflow and need to pick one. Here's the actual rule:

Two outcomes: use IF. True and false. Active and inactive. Paid and free. It's a binary split. IF is purpose-built for this. One node, two wires, done.

Three or more outcomes: use Switch. Three email categories. Four event types. Five lead tiers. Any time you're routing a single field to more than two destinations, Switch is the right tool. Full stop.

IF nodes nested inside IF nodes: you already needed Switch two nodes ago. If you've ever done something like "IF category equals support → true: IF priority equals urgent → true: [action] false: [action] false: [other path]" — that's a Switch node waiting to happen. The moment you're evaluating the same field (or the same data context) across multiple sequential IF checks, you're building a Switch by hand and making it worse.

The reason Switch is cleaner isn't just visual. It's logical. When you chain IF nodes, you're saying "check A, and if A is false, go check B, and if B is false, go check C." That's sequential logic: each check depends on the previous one failing. Switch says "check all these conditions in parallel and route to whichever one matches first." Your conditions are independent alternatives here, not sequential gates. Switch reflects that correctly and your workflow canvas actually shows it.

Setting up your first Switch node

Open the n8n canvas. Add a Switch node after whatever node produces the data you want to route on. Open the node editor. Here's what you'll see and what each piece does:

The Rules interface

By default you start in "Rules" mode. You'll see an "Add Rule" button and a growing list of outputs as you add them. Each rule you add creates one output. The condition interface inside each rule is identical to the IF node , same field selector, same operator dropdown, same value input. If you know how to configure an IF condition, you already know how to configure a Switch rule.

Click "Add Rule," configure the condition (e.g., {{ $json.category }} equals support), and you've just defined Output 0. Add another rule for Output 1. Keep going until you've defined every branch you need.

Naming your outputs

This is the part everyone skips and then regrets. By default, outputs are named "Output 0," "Output 1," "Output 2." Two weeks later you have no idea which output handles billing and which handles spam. n8n lets you rename each output directly in the rule editor. There's a name field next to each rule. Use it. Call them "support," "billing," "press," "spam." Future-you will thank present-you.

Rule 0 (name: "support")
  → {{ $json.category }} equals "support"

Rule 1 (name: "billing")
  → {{ $json.category }} equals "billing"

Rule 2 (name: "press")
  → {{ $json.category }} equals "press"

Rule 3 (name: "spam")
  → {{ $json.category }} equals "spam"

Fallback Output: enabled → log to review sheet

Connecting outputs to downstream nodes

Once you've defined your rules and saved the node, you'll see the output ports on the right side of the Switch node on the canvas. Each port corresponds to one rule (and one output). Drag a wire from each port to the node that should handle items going down that branch. You can leave a port unwired, but if you do, items that hit that rule vanish. Wire everything.

One input, many outputs

Every item that enters the Switch node gets evaluated against all rules in order. It goes to the first rule it matches. If it matches no rule and you've enabled the fallback, it goes to the fallback output. Each downstream branch only receives items that matched its specific rule. Nothing more, nothing less.

Output modes: Rules vs Expression

The Switch node offers two modes. Most people use Rules mode exclusively and never need the other one. But Expression mode exists for a reason and it's useful when the routing logic lives in the data itself rather than in hard-coded conditions.

Rules mode

This is the standard mode. You define conditions for each output, one per rule. n8n evaluates each incoming item against your conditions and routes each item to the matching output. The UI is visual and the conditions are human-readable without digging into expressions. This is what you should use for the vast majority of Switch nodes.

Expression mode

Instead of defining discrete conditions, you write a single expression that returns a number: the output index. If the expression returns 0, the item goes to Output 0. If it returns 2, it goes to Output 2. The expression evaluates against the item's data and the return value determines the destination.

{{ $json.tier === "enterprise" ? 0 : $json.tier === "pro" ? 1 : 2 }}

When is this actually useful? When the routing logic is computed or comes from the data rather than from string matching. If you have an API that returns an output index directly ({{ $json.route_to }}), Expression mode is exactly one expression and you're done. Or when the routing logic is complex enough that a nested ternary is cleaner than seven separate rules with long condition strings.

For everyday use: stick with Rules. Use Expression when conditions would get unwieldy or when you're routing on a value that's already a number or index. Don't use Expression just because it looks clever. It's harder to read at a glance and harder for someone else to maintain.

The fallback output — don't skip this

This is the part that trips people up. Not the conditions, not the output modes. The fallback.

By default, in Rules mode, items that don't match any rule get dropped silently. The workflow execution succeeds. Nothing errors. The item is just gone. If you have ten items coming in and two of them don't match any rule, you'll get eight items continuing downstream and you'll have no way of knowing you lost two unless you built the fallback in advance.

The Switch node has a dedicated "Fallback Output" setting. Enable it. When you do, an additional output port appears on the node (labeled "Fallback"), and items that match nothing land there. Connect something to that port. It doesn't have to be complex. A Set node that logs the item data and a timestamp, then writes to a Google Sheet or sends a Slack alert. Or even a No-Op node as a placeholder while you're building, with a note to add real logging later.

Practical example: my email triage Switch node has four named outputs (support, billing, press, spam) and a fallback wired to a "review" sheet in Google Sheets. Occasionally an email arrives with a category the classifier wasn't confident about. Maybe it returned null or returned a category string I didn't anticipate. Those land in the fallback, and I review them manually every few days. Without it, I'd lose those emails entirely and never know.

The fallback also serves as a canary. If the fallback output is suddenly getting a lot of items, that means something upstream changed: a new category was added, a field format shifted, the classifier started returning different values. The fallback catches it. Without it, you'd be chasing missing data with no starting point.

Real production examples from my stack

Example 1: Email category routing

My email triage bot runs every five minutes. It pulls new messages, passes them through an AI classification step, and by the time items reach the Switch node each one has a category field assigned. The Switch handles everything from there.

Output 0 "support"
  → {{ $json.category }} equals "support"
  → Action: create Notion ticket, tag as open

Output 1 "billing"
  → {{ $json.category }} equals "billing"
  → Action: Telegram alert + flag in Stripe notes

Output 2 "press"
  → {{ $json.category }} equals "press"
  → Action: save to Airtable for review queue

Output 3 "spam"
  → {{ $json.category }} equals "spam"
  → Action: archive and ignore

Fallback
  → Action: log to "uncategorized review" sheet

Why does this beat four nested IF nodes? The conditions are parallel, not sequential. Each branch does something completely different. Creating a Notion ticket has nothing to do with sending a Telegram message, and neither has anything to do with logging to Airtable. These aren't sequential gates, they're independent destinations. Representing parallel routing with sequential IF chains is just wrong structurally, and you'll feel it when you try to add a fifth category or modify one branch without touching the others.

With a Switch node: add a rule, name the output, wire it. That's it. With chained IFs: find the right node in the chain, modify the condition, check that the downstream wires didn't break, recheck all the other branches. Every. Single. Time.

Example 2: Webhook dispatch by event type

A single webhook endpoint receives multiple event types from my payment provider: subscriber.new, subscriber.cancelled, charge.refunded, trial.started. Each type needs a completely different workflow path: different nodes, different destinations, different error handling.

Output 0 "new-subscriber"
  → {{ $json.event_type }} equals "subscriber.new"
  → Action: create profile, trigger welcome sequence

Output 1 "cancellation"
  → {{ $json.event_type }} equals "subscriber.cancelled"
  → Action: tag in CRM, pause sequences, log churn

Output 2 "refund"
  → {{ $json.event_type }} equals "charge.refunded"
  → Action: update Stripe notes, notify via Slack

Output 3 "trial-start"
  → {{ $json.event_type }} equals "trial.started"
  → Action: start trial nurture sequence

Fallback
  → Action: log unknown event type to sheet for review

This is the cleanest Switch node use case. The routing field is a single string value with a finite set of known options. Each value maps to a completely separate handler. When a new event type gets added, say the payment provider adds charge.disputed , I add one rule to the Switch and wire one new branch. The fallback means I'd have caught charge.disputed landing there before I even knew I needed to handle it.

Compare this to four IF nodes chained together, each one evaluating event_type against a different value and passing non-matches down the chain. It's slower to read, it's slower to modify, and the visual canvas looks like someone ate a bowl of spaghetti and decided to model it in n8n.

Example 3: Lead tier splitting by company size

Leads arrive via form. The form collects company_size as a dropdown with predefined values. Based on that value, I route leads to completely different nurture paths, because what a solo operator needs to hear is different from what a 200-person company needs to hear, and I'm not sending the same sequence to both.

Output 0 "smb"
  → {{ $json.company_size }} equals "1-10"
  → Action: enroll in solo/SMB nurture sequence

Output 1 "mid-market"
  → {{ $json.company_size }} equals "11-100"
  → Action: enroll in mid-market follow-up flow

Output 2 "enterprise"
  → {{ $json.company_size }} equals "101+"
  → Action: high-touch alert to review queue, manual follow-up

Fallback
  → Action: default nurture sequence, flag for review

The fallback earns its keep here. Forms are filled by humans, and humans don't always behave the way your dropdown expects. Someone manages to submit without a company_size value, the field is null, nothing matches, the fallback catches them and drops them into a default sequence instead of losing them. A missed lead is a missed sale, and the fallback costs roughly thirty seconds to wire up.

Common mistakes

1. Not enabling the fallback output

Already covered this, but it's the top mistake so it deserves the top spot. Items that don't match any rule disappear by default. No error, no warning, no trace. Enable the fallback output. Wire it to something. Even a Google Sheets row or a Slack message is enough to know the fallback is firing and to see what landed there.

If you're currently staring at a workflow where items seem to disappear between two nodes and you have a Switch node in the middle. That's probably why.

2. Using Switch when you have two conditions

Switch with two outputs is just a worse IF node. It adds more visual surface area, requires you to name two outputs instead of just wiring true/false, and accomplishes nothing that IF doesn't already do more cleanly. Two outcomes: use IF. Three or more: Switch. There's no ambiguity in that rule.

3. Not naming your outputs

"Output 0," "Output 1," "Output 2," "Output 3." Two weeks from now you'll be staring at the canvas trying to remember which number was the billing path and which was the press path. Names cost nothing. Write them in. "support," "billing," "press," "spam." Now the canvas reads like documentation.

4. Forgetting that rules evaluate top to bottom

This one is subtle. If an item could match more than one rule (say your conditions overlap) — it goes to the first matching rule only. Order determines the winner. If you've got a general rule that could match almost everything and you accidentally put it first, it'll swallow items that were supposed to go to more specific rules below it.

Put specific rules first, general rules last. If you're ever confused about why items are landing in the wrong output, check rule order before anything else.

5. Using Rules mode when Expression mode would be cleaner

If your Rules configuration has grown to six or seven long condition chains that are all variations of checking the same computed value, you're probably better off writing a single expression that returns the output index. One short expression, clean and readable. Rules mode is for human-legible conditions. Expression mode is for programmatic routing. When the Rules panel starts to look like code, just write the code.

When Switch isn't the answer

Two branches: use IF. Not Switch. IF is cleaner, smaller, and purpose-built for binary decisions. Using Switch for a true/false split is like using a Swiss Army knife to slice bread — technically it works, but there's a better tool right next to it.

Complex combinatorial logic: use multiple IF nodes or a Code node. Switch works when you're routing on a single field (or a single computed value). When your routing logic depends on the intersection of multiple fields, like "if company_size is large AND plan is trial AND signup_source is organic". That's combination-logic territory. Multiple IF nodes handle sequential dependent gates better. A Code node handles complex decision trees with custom logic better. Switch is not the right tool when the routing question can't be answered by evaluating one thing at a time.

Same downstream action, different data: skip the Switch entirely. If all your branches do the same thing, just with slightly different values in the data — you don't need a Switch. Use a Set node to adjust the relevant values based on the field, then send everything down a single path. One node, one branch, same result. Adding a Switch when you don't need branching just adds complexity for no reason.

The short version

Switch exists because IF nodes weren't designed for three-plus-way routing. The moment you find yourself adding a second IF node to handle outcomes from the first IF node (more than two possible values, more than two destinations), you've passed the IF node's operating envelope. Switch is the replacement. Same condition interface, same data model, just N outputs instead of two.

Configure rules. Name your outputs. Enable the fallback. Wire everything. That's the whole thing. The rest is just getting comfortable with how the pieces connect on the canvas, which takes about one real workflow to internalize.

Every Switch node without a fallback output is an assumption that your data is perfectly clean. Your data is never perfectly clean. Enable the fallback. Wire it somewhere. This is not optional.