n8n Switch Node: When IF Nodes Aren’t Enough
The IF node in n8n handles two paths — true and false. That covers a lot of use cases, but the moment you need three or more conditional branches, you need the n8n switch node. The switch node is n8n’s multi-path router, and understanding it is essential for building workflows with real conditional logic.
This guide walks through eight practical examples covering both rules mode and expression mode, string and number data types, output renaming, and one of the most useful but least-known options in the node: sending data to all matching outputs instead of just the first match.
Rules Mode vs. Expression Mode
The n8n switch node operates in two modes. Rules mode is the default and the most common — you define a set of conditions visually, each with a data type, an operator, and a value, and the node routes each item to the first branch whose condition is true. Expression mode gives you full JavaScript expression control over which output an item goes to, which is useful when your routing logic is too complex for simple rules or when you are computing the output path dynamically.
For the vast majority of switch node use cases, rules mode is the right choice. It is faster to build, easier to read, and easier to maintain. Expression mode is there when you genuinely need it — dynamic routing, complex nested conditions, or cases where the output path depends on a calculation rather than a simple comparison.
Data Types: Strings, Numbers, and More
One of the most important things to get right when configuring the n8n switch node in rules mode is the data type. The node supports strings, numbers, booleans, date/time, arrays, and objects. The data type you select must match the actual type of the field you are comparing — if your field contains a number and you compare it as a string, the condition will not behave as expected.
String comparisons are useful for routing by category, status label, or any text-based value. Number comparisons let you create range-based routing — for example, routing ultramarathon finish times into “fast,” “average,” and “finisher” buckets based on whether the time is less than 10 hours, less than 14 hours, or anything else. Always verify the data type of your input field before setting up your rules, and use the output of a previous node’s test execution to confirm what type n8n is actually receiving.
Renaming Outputs for Clarity
By default, the n8n switch node labels its outputs with integers — output 0, output 1, output 2, and so on. These labels appear in the workflow editor on the connection lines leaving the switch node, and they become very hard to follow as the number of branches grows.
Every rule in the switch node has a rename output option. Turning this on lets you give each output a meaningful name — “fast,” “average,” “finisher” instead of 0, 1, 2. This is a small thing that makes a significant difference when you return to a workflow days or weeks later. Make it a habit to rename outputs whenever you use the switch node with more than two branches.
First Match vs. All Matching Outputs
By default, the n8n switch node sends each item to the first rule whose condition is true, then stops evaluating. This is the expected behavior for most routing scenarios — you want an item to go into exactly one branch.
But there is an option worth knowing: send data to all matching outputs. When this is enabled, the node evaluates every rule for each item and sends the item to every branch where the condition is true. An item might then appear in multiple downstream branches simultaneously. This is rarely what you want for category routing, but it is genuinely useful in notification and fan-out scenarios — for example, triggering multiple alerts or actions simultaneously when an item meets multiple criteria at once.
Practical Examples: Number-Based Routing
Number comparisons are among the most common switch node use cases. A finish time, a score, a count, a dollar amount — any numeric field can become the basis for multi-path routing. Set your data type to number, choose an operator (is less than, is greater than, equals, is between), and define the threshold value. Rename the output to reflect what that range means in your context.
A practical note: when using “is less than” with multiple thresholds, remember that the node evaluates rules in order and stops at the first match by default. So if you have “less than 10” as rule 1 and “less than 14” as rule 2, an item with value 7 will match rule 1 and go to that branch — it will never reach rule 2. Order your rules from most specific to most general, and use the all matching outputs option only when you actually need fan-out behavior.
Practical Examples: String-Based Routing
String comparisons in the n8n switch node handle text-based routing. Common operators include equals, contains, starts with, ends with, and regex match. Equals is the most reliable for clean categorical data — status fields, type labels, country codes. Contains is useful when you are matching against free-text fields where exact values are not guaranteed.
Case sensitivity matters: by default, string comparisons in the switch node are case-sensitive. If your data might come in with inconsistent capitalization, either normalize it in an Edit Fields node before the switch, or use a case-insensitive comparison option. A switch node that routes “Active” correctly but drops “active” silently is a common debugging headache that is easy to prevent.
Building Readable Multi-Branch Workflows
The switch node becomes the centerpiece of any workflow with meaningful conditional logic. A few practices make these workflows easier to build and maintain. First, always rename outputs — the time investment is minimal and the readability gain is significant. Second, keep the number of branches manageable — four to six is the practical limit before a switch node becomes hard to follow visually. Third, add a fallback branch for unexpected values — a final rule that catches anything the previous rules did not match, logs it, or sends it to a review queue.
If your routing logic is becoming genuinely complex — nested conditions, dynamic values, conditions that depend on computations — consider whether expression mode or a pre-processing step before the switch node would make the logic clearer. The switch node is powerful, but readable workflows are easier to debug and extend than clever ones.
