Introduction

Most real-world workflows don't process every item the same way. A customer who just signed up needs a welcome email. A customer who just cancelled needs a churn flow. An order marked "urgent" routes differently than a standard one. This is where conditional logic comes in.

n8n gives you two nodes for this: the IF node for binary decisions (true/false, yes/no), and the Switch node for multi-path routing based on a value that can match several cases. Understanding when to use each one — and how to wire them correctly — is the difference between a clean workflow and a tangled mess.

The IF Node: Binary Splits

The IF node evaluates a single condition and sends each item down one of two output paths: true or false. You connect different downstream nodes to each output, and n8n routes items automatically based on the result.

To configure it, you pick a value (usually a field from the incoming item), choose an operation, and set a comparison value. The available operations include: equals, not equals, contains, starts with, ends with, is empty, greater than, less than, and a few others depending on data type.

For example, imagine you're processing order data and want to flag high-value orders. Your items look like this:

{
  "orderId": "ORD-991",
  "customer": "Alice",
  "total": 340,
  "status": "pending"
}

In the IF node you would set: Value 1 = {{ $json.total }}, Operation = Greater Than, Value 2 = 200. Items where total exceeds 200 go to the true branch; the rest go to the false branch. You then connect a Slack notification node to the true output and a simple "do nothing" or logging node to the false output.

One thing to watch: if you leave the false output unconnected, n8n will silently drop those items. That's sometimes intentional, but make sure it's a deliberate choice.

The Switch Node: Multi-Path Routing

When you have more than two outcomes, chaining multiple IF nodes gets messy fast. The Switch node solves this by letting you define multiple rules, each with its own output. Each item is evaluated against the rules in order, and it exits through the first matching output.

A typical use case is routing support tickets by priority:

{
  "ticketId": "T-204",
  "subject": "Cannot login",
  "priority": "high"
}

In the Switch node you define three rules:

Rule 1 — Value: {{ $json.priority }}, Operation: Equals, Comparison: "high" → Output 0 Rule 2 — Value: {{ $json.priority }}, Operation: Equals, Comparison: "medium" → Output 1 Rule 3 — Value: {{ $json.priority }}, Operation: Equals, Comparison: "low" → Output 2

You then wire Output 0 to a PagerDuty node, Output 1 to a Jira node, and Output 2 to a spreadsheet logger. Each ticket automatically lands in the right place without any manual sorting.

The Switch node also has a Fallback Output option. Enable it to catch any item that doesn't match any rule — the equivalent of a default case in a switch statement. Always configure this when the incoming values could be anything other than what you explicitly listed.

Expressions in Conditions

Both nodes support n8n expressions, which means your conditions can be dynamic rather than hardcoded. You reference incoming data with {{ $json.fieldName }} and can apply JavaScript inside the double curly braces.

For example, to check whether an order was placed more than 7 days ago:

{{ Date.now() - new Date($json.createdAt).getTime() > 7 * 24 * 60 * 60 * 1000 }}

Set this as Value 1, use the operation "Is True", and leave Value 2 empty. This pattern lets you build time-based routing, string manipulation checks, or any boolean logic that a simple field comparison can't handle.

You can also combine fields. To route only items where status is "active" AND plan is "pro", chain two IF nodes — one checking status, the other (on the true branch) checking plan. The Switch node doesn't natively support AND/OR logic within a single rule, so chaining is the right approach there.

Common Mistakes

Type mismatches are the most frequent issue. If {{ $json.total }} arrives as the string "340" instead of the number 340, a Greater Than comparison will fail unexpectedly. Use the Set node upstream to enforce types when you're not sure what's coming in.

Another common error is forgetting that Switch evaluates rules top to bottom and stops at the first match. If you put a broad rule before a specific one, the specific rule will never trigger. Order your rules from most specific to least specific.

Finally, watch out for items that carry no value at all for the field you're testing. An undefined or null field will not equal "high" — it will fall through to fallback. That's correct behavior, but only if you have a fallback configured.

Summary

Use the IF node when you need a clean true/false split — it's fast to set up and easy to read. Use the Switch node when you have three or more distinct paths based on a field's value. In both cases, always account for the items that don't match your expected conditions, either by connecting the false/fallback output or making a deliberate choice to drop them. Expressions give both nodes real power when simple value comparisons aren't enough.