n8n Switch Node

Binary decisions rarely reflect real business logic. Orders do not just succeed or fail. They ship domestically, internationally, require signature confirmation, or qualify for same-day delivery. Customers are not simply valid or invalid. They fall into bronze, silver, gold, and platinum tiers. Support tickets route to billing, technical, sales, or escalation queues based on category, urgency, and customer status.

The Switch node handles these multi-path scenarios. While the If node splits workflows into two paths, the Switch node routes data to any number of destinations based on rules you define. Think of it as a traffic controller directing items to specific lanes rather than a simple fork in the road.

The Multi-Path Routing Problem

Complex workflows require sophisticated routing. Consider these common scenarios:

An order processing system routes orders by shipping method (standard, express, overnight, international)
A support ticket workflow directs tickets to specialized teams based on category
A lead scoring system segments contacts by tier for different nurturing campaigns
An API response handler routes data differently based on status codes (200, 400, 401, 404, 500)

You could chain multiple If nodes together, but this creates hard-to-follow spaghetti logic. The Switch node provides a cleaner solution: define all your routing rules in one place, and items flow to the appropriate outputs based on which rules they match.

What the Switch Node Does

The Switch node examines each item against your routing rules:

Evaluates conditions using the same operators as the If node (equals, contains, greater than, regex, etc.)
Routes to multiple outputs rather than just true/false
Supports two modes: visual Rules mode for simple conditions, and Expression mode for programmatic control
Handles unmatched items with configurable fallback behavior
Can route to multiple outputs simultaneously when items match multiple rules

Data flows in, the node checks your rules in order, and routes each item to matching outputs. Unlike If nodes, Switch does not force a binary choice. Items go exactly where your business logic dictates.

What You’ll Learn

When to choose Switch over If or Filter nodes
How to configure Rules mode for visual condition building
When and how to use Expression mode for programmatic routing
Fallback options for handling items that match no rules
How to route items to multiple outputs simultaneously
Common mistakes that cause routing failures and how to fix them
Real-world examples for tier-based, regional, and status-based routing

When to Use the Switch Node

Before configuring the Switch node, understand when it is the right choice versus other flow control options.

Scenario	Best Choice	Why
Route by customer tier (bronze/silver/gold/platinum)	Switch node	Four distinct paths need one node, not chained Ifs
Binary yes/no decision (valid/invalid)	If node	Two outcomes is what If does best
Route by geographic region (US/EU/APAC/Other)	Switch node	Multiple regions with fallback for unknown
Filter out invalid records	Filter node	Dropping items, not routing them
Route by order status (pending/processing/shipped/delivered/cancelled)	Switch node	Five distinct statuses need Switch
Check if API response succeeded	If node	Success/failure is binary
Dynamic routing based on calculated value	Switch node (Expression mode)	Programmatic output selection
Remove duplicates or empty values	Filter node	Data cleanup, not routing

Rule of thumb: Use If for binary decisions. Use Switch when you have three or more distinct destinations. Use Filter when you want to remove items rather than route them. If you find yourself nesting multiple If nodes, that is a signal to refactor using Switch instead.

Understanding the Two Modes

The Switch node offers two configuration approaches. Each suits different use cases.

Rules Mode

Rules mode provides a visual interface for building routing conditions. You define a rule for each output, specifying the data type, comparison operator, and target value. This mode works best when:

You have a fixed number of known routing destinations
Conditions are straightforward (status equals “pending”, region contains “EU”)
You want visual clarity over programmatic control
Team members who are not developers need to understand and modify the logic

In Rules mode, you add rules like building blocks. Each rule maps to an output, and you configure the condition that triggers that output.

Expression Mode

Expression mode gives you programmatic control. Instead of visual rules, you write a JavaScript expression that returns the output index (0, 1, 2, etc.) where the item should go. This mode works best when:

Output selection depends on complex calculations
You need dynamic routing based on multiple factors
The number of outputs might change based on data
You are comfortable writing expressions

In Expression mode, you specify how many outputs the node has, then write an expression that calculates which output each item goes to.

Quick Comparison

Feature	Rules Mode	Expression Mode
Configuration style	Visual, point-and-click	JavaScript expression
Best for	Fixed routing rules	Dynamic calculations
Learning curve	Lower	Higher
Flexibility	Moderate	Maximum
Readability	Easier for non-developers	Requires expression knowledge
Rule complexity	Simple to moderate	Any complexity

Most workflows use Rules mode. Switch to Expression mode when your routing logic requires calculations or dynamic behavior that visual rules cannot express cleanly.

Rules Mode Deep Dive

Rules mode is the default and most common configuration approach. Here is everything you need to know to configure it effectively.

Creating Routing Rules

Each rule in Rules mode consists of:

Data type: String, Number, Boolean, Date & Time, Array, or Object
Comparison operator: Varies by data type
Values: The data to check (left value) and what to compare against (right value)

To add a rule:

Open the Switch node
Click Add Routing Rule
Configure the condition
Repeat for each output you need

Available Operators by Data Type

String Operators:

Operator	Matches When	Example
equals	Exact match	`"pending"` equals `"pending"`
not equals	No match	`"pending"` not equals `"approved"`
contains	Substring found	`"[email protected]"` contains `"@example"`
not contains	Substring absent	`"[email protected]"` not contains `"@example"`
starts with	Begins with value	`"order_12345"` starts with `"order_"`
ends with	Ends with value	`"report.pdf"` ends with `".pdf"`
matches regex	Pattern matches	`"ABC-123"` matches `[A-Z]+-\d+`
is empty	String is `""`	Empty string check
is not empty	Has content	Non-empty string check

Number Operators:

Operator	Matches When	Example
equals	Same value	`100` equals `100`
not equals	Different value	`100` not equals `50`
greater than	Left exceeds right	`150` greater than `100`
less than	Left below right	`50` less than `100`
greater than or equal	Left at least right	`100` greater than or equal `100`
less than or equal	Left at most right	`99` less than or equal `100`

Boolean Operators:

Operator	Matches When
is true	Value is `true`
is false	Value is `false`
exists	Field is defined
does not exist	Field is absent

Date & Time Operators:

Operator	Matches When
is after	Date occurs after comparison
is before	Date occurs before comparison
equals	Dates match exactly

Fallback Output Options

What happens when an item matches no rules? The Switch node provides three options:

Option	Behavior	Use When
None	Item is dropped silently	Unmatched items are irrelevant
Extra Output	Routes to a separate fallback output	You want to handle unknown cases
Output 0	Routes to first output	Default handling same as first rule

Recommended: Use Extra Output in most cases. Silent dropping can hide data problems. A fallback output lets you log, alert, or handle unexpected values explicitly.

Send Data to All Matching Outputs

By default, the Switch node stops at the first matching rule. If an item matches Rule 1, it goes to Output 1 and skips checking subsequent rules. This mirrors how a JavaScript switch statement with break works.

Sometimes you need an item to go to multiple outputs. Enable Send data to all matching outputs in the node options to change this behavior.

Example scenario: A product tagged with both “electronics” and “sale” should route to both the electronics processing queue AND the sale items queue.

With “Send to all matching outputs” off: Item goes only to first matching output With “Send to all matching outputs” on: Item goes to every output where conditions match

Warning: When this setting is off, rule order matters critically. Place your most specific or highest-priority rules first.

Node Options

Additional options fine-tune Switch behavior:

Option	Effect
Ignore Case	String comparisons ignore uppercase/lowercase
Less Strict Type Validation	Attempts type conversion before comparing
Send data to all matching outputs	Routes to every matching rule, not just first

Enable Ignore Case when dealing with user-generated data where capitalization varies. Enable Less Strict Type Validation when data types are inconsistent (API returning numbers as strings, for example).

Expression Mode Deep Dive

Expression mode provides programmatic control over routing. Instead of visual rules, you write an expression that calculates the output index for each item.

Configuration

In Expression mode, you configure:

Number of Outputs: How many outputs the node should have (2, 3, 4, etc.)
Output Index: An expression that returns 0, 1, 2, etc. to indicate which output each item goes to

Basic Expression Examples

Route based on numeric tier:

{{ $json.tier_level }}

If tier_level is 0, routes to Output 0. If tier_level is 1, routes to Output 1, and so on.

Map status strings to output indexes:

{{
  {
    "pending": 0,
    "processing": 1,
    "shipped": 2,
    "delivered": 3
  }[$json.status] ?? 0
}}

This creates a lookup object that maps status values to output indexes. Unknown statuses default to 0 using the nullish coalescing operator.

Calculate output based on order value:

{{
  $json.order_total >= 1000 ? 2 :
  $json.order_total >= 500 ? 1 : 0
}}

Orders $1000+ go to Output 2, orders $500-999 go to Output 1, smaller orders go to Output 0.

When Expression Mode Shines

Expression mode excels when:

Routing logic involves calculations: Determine tier based on computed score
You need dynamic behavior: Output varies based on time, date, or external data
Rules are numerous: Mapping 20+ statuses is cleaner with a lookup object
Logic is already programmatic: Referencing Code node output or complex expressions

For detailed expression syntax and patterns, see our n8n expressions guide.

Expression Mode Pitfalls

Pitfall 1: Returning non-integer values

The output index must be an integer. If your expression returns 1.5 or “1”, routing may fail or behave unexpectedly. Always ensure integer output:

{{ Math.floor($json.calculated_tier) }}

Pitfall 2: Returning out-of-range indexes

If you specify 3 outputs but your expression returns 5, the item has nowhere to go. Validate your expression covers all possible values.

Pitfall 3: Forgetting fallback values

If $json.status is undefined, your lookup returns undefined, causing routing errors. Always provide fallbacks:

{{ statusMap[$json.status] ?? defaultOutput }}

Your First Switch Node

Walk through a practical example: routing orders by customer tier to different processing queues.

Step 1: Add the Switch Node

Open your n8n workflow
Click + to add a node
Search for “Switch”
Click to add it to your canvas
Connect it to your data source (webhook, database, HTTP request, etc.)

Step 2: Configure the Mode

By default, the node opens in Rules mode. For this example, we will stay in Rules mode since we have clear, fixed tiers.

Step 3: Create Routing Rules

We will route orders based on customer_tier field values: bronze, silver, gold, platinum.

Rule 0 (Bronze):

Data Type: String
Operation: equals
Value 1: {{ $json.customer_tier }}
Value 2: bronze

Rule 1 (Silver):

Data Type: String
Operation: equals
Value 1: {{ $json.customer_tier }}
Value 2: silver

Rule 2 (Gold):

Data Type: String
Operation: equals
Value 1: {{ $json.customer_tier }}
Value 2: gold

Rule 3 (Platinum):

Data Type: String
Operation: equals
Value 1: {{ $json.customer_tier }}
Value 2: platinum

Step 4: Configure Fallback

Click Options
Set Fallback Output to Extra Output

This creates a fifth output for orders with unknown tier values.

Step 5: Test the Node

If you have pinned data or previous execution data, click Test step
Examine the output panel
You should see items distributed across outputs based on their tier

Step 6: Connect Downstream Nodes

Each output can connect to different processing:

Output 0 (Bronze): Standard processing queue
Output 1 (Silver): Slightly prioritized queue
Output 2 (Gold): Priority queue with notifications
Output 3 (Platinum): VIP queue with personal outreach
Output 4 (Fallback): Log unknown tiers, alert for review

Understanding the Outputs

When you test or execute the workflow:

Each item goes to exactly one output (unless “Send to all matching” is enabled)
Items maintain their full data structure
Empty outputs are normal when no items match that rule
The fallback catches anything that slips through

Advanced Patterns

Combining Multiple Conditions (AND Logic)

Each rule in Rules mode checks a single condition. What if you need items matching multiple criteria?

Problem: Route only VIP customers with orders over $500.

Solution 1: Expression in condition

Use an expression that evaluates both conditions:

{{ $json.customer_tier === "platinum" && $json.order_total > 500 }}

Set the rule to check if this expression equals true.

Solution 2: Concatenate values

Combine the conditions into a single comparable value:

{{ $json.customer_tier + "_" + ($json.order_total > 500 ? "high" : "low") }}

Then create rules matching platinum_high, platinum_low, gold_high, etc.

Solution 3: Use Expression mode

Write a single expression handling all combinations:

{{
  $json.customer_tier === "platinum" && $json.order_total > 500 ? 0 :
  $json.customer_tier === "platinum" ? 1 :
  $json.order_total > 500 ? 2 : 3
}}

Dynamic Routing Based on Data

Use expressions referencing configuration or calculated values:

// Route to output based on region mapping from config node
{{ $('Config').first().json.regionOutputMap[$json.region] ?? 0 }}

This reads a mapping object from an earlier node, enabling route changes without editing the Switch node.

Routing by Array Contents

Check if arrays contain specific values:

Expression mode:

{{
  $json.tags.includes("urgent") ? 0 :
  $json.tags.includes("priority") ? 1 : 2
}}

Rules mode with expression:

// Left value
{{ $json.tags.includes("urgent") }}

// Compare equals true

Cascading Priority Routing

When items could match multiple rules but should only go to the highest priority match:

Keep “Send to all matching outputs” off (default)
Order rules by priority, highest first
First match wins

Example order for support tickets:

Rule 0: Security issues (highest priority)
Rule 1: System outages
Rule 2: Customer escalations
Rule 3: Standard technical
Rule 4: Billing inquiries
Fallback: Uncategorized

A security-related system outage matches both Rules 0 and 1, but goes only to Rule 0 because it is checked first.

Common Mistakes and How to Fix Them

After reviewing community forum discussions and support requests, these are the mistakes that trip up most users.

Mistake 1: Rule Order Issues

Symptom: Items route to unexpected outputs when multiple rules could match.

Cause: By default, Switch stops at the first matching rule. Rule order determines routing when items could match multiple conditions.

Example:

Rule 0: order_total > 100
Rule 1: order_total > 500
Rule 2: order_total > 1000

A $1500 order matches all three but goes only to Rule 0 (first match).

Fix: Reorder rules from most specific to least specific:

Rule 0: order_total > 1000
Rule 1: order_total > 500
Rule 2: order_total > 100

Now the $1500 order correctly matches Rule 0.

Mistake 2: Type Mismatches in Comparisons

Symptom: Condition should match but routes to fallback instead.

Cause: Comparing different types. String "100" does not equal number 100 in strict mode.

Example:

API returns: status = "1" (string)
Rule checks: status equals 1 (number)
Result: No match, goes to fallback

Fix options:

Enable Less Strict Type Validation in options
Convert in expression: {{ Number($json.status) }}
Compare as string: "1" instead of 1

Mistake 3: Expression Mode Returning Wrong Index

Symptom: Items route to wrong outputs or fail with errors.

Cause: Expression returning non-integer, undefined, or out-of-range values.

Example problematic expressions:

// Returns string instead of number
{{ $json.tier === "gold" ? "2" : "0" }}

// Returns undefined when status unknown
{{ statusMap[$json.status] }}

// Returns 5 when only 3 outputs configured
{{ $json.calculated_output }}

Fix: Always return integers within range with fallbacks:

{{
  Math.floor(
    Math.min(
      $json.calculated_output ?? 0,
      2  // Max valid output index
    )
  )
}}

Mistake 4: Missing Fallback for Unmatched Items

Symptom: Items disappear from workflow. No error, no output, they just vanish.

Cause: Fallback set to “None” and item matches no rules.

Example: Status values include “cancelled” but no rule handles it.

Fix: Always configure fallback to Extra Output unless you explicitly want unmatched items dropped. Add logging or alerting on the fallback output to catch unexpected values.

Mistake 5: Confusing Switch with Nested If Nodes

Symptom: Building complex nested If structures when Switch would be cleaner.

Red flags you should use Switch:

Three or more If nodes in sequence
If node outputs connecting to more If nodes
Difficulty following which path leads where
Team members cannot understand the routing logic

Fix: Refactor to a single Switch node. Map each final destination to a Switch rule. One node, clear routing, easier maintenance.

Use our workflow debugger to identify routing issues across your workflow.

Switch vs If vs Filter

Choosing the right node for conditional logic affects workflow readability and maintainability.

Comparison Table

Criteria	Switch Node	If Node	Filter Node
Number of outputs	Unlimited	2 (true/false)	1 (matching only)
Non-matching items	Fallback output	False output	Dropped
Best for	Multi-path routing	Binary decisions	Data cleanup
Configuration modes	Rules or Expression	Rules only	Rules only
Send to multiple outputs	Yes (optional)	No	N/A
Typical scenario	Route by category	Yes/no check	Remove invalid items

Decision Flowchart

Ask these questions in order:

Do I need to route items to different paths?
- No, just remove bad data → Filter node
- Yes, continue to question 2
How many distinct paths do I need?
- Exactly 2 paths → If node
- 3+ paths → Switch node
Can items go to multiple paths simultaneously?
- Yes → Switch node with “Send to all matching” enabled
- No → Either If or Switch depending on path count

When Each Node Excels

Switch node strengths:

Categorizing by status, tier, region, type
Complex routing with many destinations
Multi-output routing (one item to many paths)
Cleaner than nested If nodes

If node strengths:

Binary decisions (valid/invalid, success/failure)
Simple threshold checks (above/below limit)
Two-path workflows where both paths need processing

Filter node strengths:

Data validation before processing
Removing test data, empty records, invalid formats
Single output stream of clean data

For more guidance on workflow structure, see our n8n workflow best practices guide.

Real-World Examples

Example 1: Route by Customer Tier

Scenario: Process orders differently based on customer loyalty tier.

Configuration (Rules mode):

Rule	Condition	Output Use
0	`customer_tier` equals `platinum`	VIP processing
1	`customer_tier` equals `gold`	Priority queue
2	`customer_tier` equals `silver`	Standard plus
3	`customer_tier` equals `bronze`	Standard queue
Fallback	Extra output	Unknown tier handling

Each output connects to appropriate downstream processing with different SLAs, notifications, and handling procedures.

Example 2: Route by Geographic Region

Scenario: Send orders to regional fulfillment centers.

Configuration (Rules mode):

Rule	Condition	Output Use
0	`shipping_country` matches regex `^(US\|CA)$`	North America center
1	`shipping_country` matches regex `^(GB\|DE\|FR\|ES\|IT)$`	Europe center
2	`shipping_country` matches regex `^(JP\|KR\|AU\|NZ\|SG)$`	APAC center
Fallback	Extra output	Review for manual routing

Using regex patterns handles multiple countries per rule efficiently.

Example 3: Route by Order Status

Scenario: Different workflows for different order states.

Configuration (Expression mode):

Number of outputs: 5

Output index expression:

{{
  {
    "pending": 0,
    "processing": 1,
    "shipped": 2,
    "delivered": 3,
    "cancelled": 4
  }[$json.status] ?? 4
}}

Expression mode is cleaner here than five individual rules, and unknown statuses route to the cancelled/exception handling path.

Example 4: Dynamic Routing Based on Score

Scenario: Route leads based on calculated lead score.

Configuration (Expression mode):

Number of outputs: 4

Output index expression:

{{
  $json.lead_score >= 80 ? 0 :
  $json.lead_score >= 60 ? 1 :
  $json.lead_score >= 40 ? 2 : 3
}}

Output 0: Hot leads (80+) for immediate sales contact
Output 1: Warm leads (60-79) for nurturing campaign A
Output 2: Cool leads (40-59) for nurturing campaign B
Output 3: Cold leads (under 40) for long-term drip

Example 5: Multi-Path Routing (Tags)

Scenario: Products with certain tags need multiple processing paths simultaneously.

Configuration:

Enable Send data to all matching outputs
Create rules for each tag:

Rule	Condition	Output Use
0	`tags` array contains `featured`	Update featured products page
1	`tags` array contains `sale`	Update sale items list
2	`tags` array contains `new`	Send to new arrivals email
3	`tags` array contains `limited`	Trigger low stock alerts

A product tagged ["featured", "sale", "limited"] routes to outputs 0, 1, and 3 simultaneously.

Pro Tips and Best Practices

1. Name Your Switch Node Outputs

Instead of “Switch” with outputs “0, 1, 2”, rename both the node and annotate what each output handles:

Node: “Route by Customer Tier”
Add sticky notes near each output: “Platinum”, “Gold”, “Silver”, “Bronze”, “Unknown”

This makes workflows self-documenting and debugging easier.

2. Always Configure Fallback

Even if you think you have covered all cases, data surprises you. Set fallback to Extra Output and connect it to logging or alerting. Silent data loss is worse than handling an exception.

3. Test All Paths

Before going to production, verify each output path:

Pin data samples that should route to each output
Test that items actually arrive at expected destinations
Verify fallback catches edge cases correctly

Test edge cases: empty strings, null values, unexpected types.

4. Keep Rules Simple

If a single rule becomes complex, consider:

Using Expression mode instead
Pre-processing data to simplify conditions
Breaking into multiple simpler rules

Complex rules are harder to debug and maintain.

5. Document Complex Expressions

When using Expression mode, add a sticky note explaining:

What the expression calculates
What each output index means
Edge cases the expression handles

Future you (and teammates) will appreciate the context.

6. Monitor Output Distribution

In production, track how items distribute across outputs. If you expect 25% per tier but see 90% going to fallback, something is wrong with either:

Your rules/expressions
Incoming data quality
Your assumptions about the data

Our workflow development services can help design robust routing logic for complex business requirements. For strategic guidance on workflow architecture, explore our consulting services.

Frequently Asked Questions

When should I use Switch instead of multiple If nodes for conditional routing?

Use Switch when you have three or more distinct routing destinations. Chaining multiple If nodes creates harder-to-follow workflow spaghetti where tracing a specific path requires following multiple branches. Switch consolidates all routing logic into one node with clear outputs. A practical rule: if you are about to connect an If node’s output to another If node, stop and consider Switch instead. Switch is also better when you might need to add more routes later since adding a rule is simpler than inserting another If node into a chain. The only time multiple If nodes make sense is when the routing decisions are truly independent and happen at different points in your workflow, not when they are sequential route-or-continue decisions.

How do I route an item to multiple outputs simultaneously?

Enable the Send data to all matching outputs option in the Switch node settings. By default, Switch stops checking rules after the first match, similar to a JavaScript switch statement with break. When you enable this option, the node evaluates all rules and routes items to every output where conditions match. This is useful for scenarios like tagging systems where a product might be both “featured” AND “on sale” and needs to trigger both the featured update AND the sale notification workflows. Note that this creates copies of the item flowing through multiple paths, so downstream nodes receive the same item independently. Ensure your workflow logic handles potential duplicate processing appropriately.

Can I combine multiple conditions with AND logic in a single Switch rule?

Not directly in the Rules mode UI, but you can achieve AND logic using expressions. Instead of checking a single field, create an expression that evaluates multiple conditions and returns a boolean. For example, to match only platinum customers with orders over $500, use the expression {{ $json.customer_tier === "platinum" && $json.order_total > 500 }} as your left value, then set the rule to check if it equals true. Alternatively, you can concatenate the relevant values into a combined string like {{ $json.tier + "_" + $json.region }} and match against combined patterns like platinum_US. For truly complex multi-condition logic, Expression mode often provides cleaner solutions where you can write full JavaScript conditional expressions to calculate the appropriate output index.

What happens when no rules match and I do not have a fallback configured?

By default, the item disappears silently. It does not cause an error, does not appear in any output, and continues no further in the workflow. This is the behavior when Fallback Output is set to “None”. While this might seem convenient for filtering out irrelevant items, it creates hidden data loss that is difficult to debug. You will not know items are being dropped unless you compare input counts to output counts. Best practice: always set Fallback Output to Extra Output and connect that output to at least a logging node. This way, unexpected values trigger visible handling rather than silent disappearance. Even if you eventually decide to ignore fallback items, explicitly handling them proves you considered the case rather than overlooking it.

How do I use Expression mode to calculate output dynamically based on data?

Expression mode replaces visual rules with a JavaScript expression that returns an integer output index. First, set the Number of Outputs to however many destinations you need. Then write an expression in the Output Index field that evaluates each item and returns 0, 1, 2, etc. For simple mappings, use a lookup object: {{ {"pending": 0, "approved": 1, "rejected": 2}[$json.status] ?? 2 }}. For threshold-based routing, use ternary operators: {{ $json.score >= 80 ? 0 : $json.score >= 50 ? 1 : 2 }}. Always include a fallback using the nullish coalescing operator (??) to handle undefined values. Ensure your expression always returns a valid integer within the configured output range. Test thoroughly with sample data covering all expected values and edge cases. For complex expressions, use our expression validator tool to catch errors before execution.