n8n IF Node & Switch Node: Condition Config & Branch Routing

Conditional routing splits a workflow into separate paths based on data‑driven rules, and n8n provides two core nodes for this: the IF node for binary true/false decisions, and the Switch node for multi‑way routing with three or more outputs. The IF node evaluates conditions with 10 comparison operators across five data types, combined with AND/OR logic. The Switch node operates in two modes—Rules (visual builder) and Expression (code‑based)— supporting unlimited output branches with a fallback output for unmatched items [1] [2].

How does the n8n IF node create a true/false branching path?

The IF node evaluates a single condition or a set of conditions combined with AND/OR logic against each incoming data item, then routes it to the true branch if all conditions match, or to the false branch otherwise. It provides 10 comparison operators—equals, not equals, greater than, less than, greater/less than or equal to, contains, not contains, is empty, is not empty—across five data types. [1]

The IF node’s “Combine” field controls whether multiple conditions are joined with AND (all must match) or OR (any must match) logic. Each branch can connect to any number of subsequent nodes, enabling different processing chains for matched and unmatched items. A straightforward example: check if an invoice total exceeds $1,000; route high‑value invoices to a manager approval flow and low‑value ones directly to payment processing. For real‑world customer routing by country and name, the n8n blog’s country‑based routing tutorial provides a complete walkthrough [3]. To pair the IF node with data recombination downstream, see the core nodes guide with Merge node patterns.

What conditions, operators, and expression patterns can you use in an n8n IF node?

The IF node supports seven data types for comparison: String (equals, contains, regex, isEmpty), Number (equals, greater, less, range), Date & Time (is after, is before), Boolean (is true, is false), and Array/Object (exists, isEmpty, contains). The left operand pulls from a field, an expression like {{ $json.price }}, or a static value. [3]

Advanced patterns combine expressions and functions: for instance, {{ $json.tags.includes("urgent") ? 'high' : 'normal' }} pre‑processes a field before the IF condition evaluates it. The “Ignore Case” option (turned on by default) allows case‑insensitive string comparison; turn it off to enforce exact letter case. A common edge case arises when webhooks send empty or missing fields—the IF node may not natively recognize these as empty; using {{ $json.field || '' }} forces the value into an empty string for reliable evaluation [4]. For conditional logic that spans multiple items or requires programmatic transformation, combine IF with the Code node transformation guide.

How does the Switch node route data to three or more branches based on multiple conditions?

The Switch node evaluates multiple conditions simultaneously and routes each data item to exactly one matching output branch. You define routing rules based on a single field or expression and choose from two modes: Rules mode (visual dropdown‑based condition builder: string, number, date, boolean, array, object comparisons) and Expression mode (JavaScript expression returning the output index programmatically). [2]

In Rules mode, the node supports all five data types—String, Number, Date & Time, Boolean, and Array/Object—each with their full set of comparison operations (e.g., String supports equals, not equals, contains, begins with, ends with, regex). For date routing, select “Date & Time > is after” and supply a reference date; for numeric ranges, chain conditions in ascending order (e.g., values 1-5 then 6-10 then 11-13) with “Send data to all matching outputs” disabled to route each value into exactly one bucket [5]. A critical configuration option: Fallback Output offers three choices—None (ignore unmatched items), Extra Output (send to a separate fallback branch), or Output 0 (route to the first rule’s output). For the complete taxonomy of available data type comparisons per mode, see the official Switch node parameter documentation [6]. To understand when Switch becomes the better choice over chained IF nodes, see the trigger nodes guide for workflow activation patterns.

When should you use an IF node instead of a Switch node in n8n?

Use an IF node when the decision is strictly binary— true or false—such as checking if a field is empty, comparing a single threshold, or validating user permissions. An IF node with Combine set to AND handles 10 comparison operators perfectly for small sets of conditions, and its two output connectors make the workflow logic immediately clear for yes/no decisions. [3]

Switch to the Switch node when you have three or more distinct outcomes that all branch from the same decision point—such as routing support tickets by category (billing, technical, return), leads by country (US, UK, CO, others), or orders by status (pending, shipped, returned, cancelled). The quick rule of thumb: If you find yourself stacking three or more IF nodes in sequence to simulate multi‑way routing, a single Switch node with a fallback output will be more readable and maintainable [7]. For complex systems with many independent binary choices, bitmasking— assigning each option a power‑of‑2 value and routing on the summed number—can replace long chains of IF/Switch nodes with a single Switch node [8]. For more on designing clean, maintainable branching architectures, see SplitInBatches loop and batch processing guide.

How do you implement range routing and bitmasking in the Switch node?

For range routing—categorizing numeric values into buckets—configure Switch rules in ascending order (e.g., values < 5, then values <= 10, then values <= 13) with “Send data to all matching outputs” disabled. This sequential evaluation routes each value into exactly one bucket: 1–4 go to the first output, 5–10 to the second, 11–13 to the third [5].

Bitmasking is an advanced technique that replaces tangled condition mazes with a single number: assign each independent choice a power‑of‑2 value (Drink Coffee = 1, Drink Tea = 2, Food Croissant = 4). Add the values for the customer’s order; the sum is unique for every combination. A single Switch node then routes Coffee (1), Tea (2), Coffee + Croissant (5), or Everything (7) to the correct workflow branch. This scales from three choices (3 possible combinations) to N choices (2^N combinations) without adding nodes, and applies anywhere you have multiple independent flags: user permissions, feature flags, survey responses, or game states [8]. For implementing bitmasking programmatically before routing, pair it with the Code node transformation guide.

How does n8n’s branch execution order and performance work with IF and Switch nodes?

In n8n v1.0+, branches from conditional nodes execute sequentially from top to bottom on the canvas. When two branches sit at the same height, the leftmost branch executes first. You can change this order in the workflow settings. This matters when downstream nodes depend on results from a prior branch—always place the branch that must complete first above the dependent branch. [9]

For performance, the Switch node checks each rule sequentially and stops at the first match (when “Send data to all matching outputs” is off)— arrange the most frequent matches first to minimize average evaluation time. For more than 20 rules, consider using a Code node with a lookup table to reduce node overhead. The “Split → Process → Merge” pattern (branch with IF/Switch, process each path independently, then reunify with a Merge node) is the canonical design for complex workflows; use the Merge node’s Combine mode with Matching Fields for inner‑join‑style recombination [6]. For full details on the Merge node and the five join types it supports, see the core nodes guide (HTTP Request, Set, IF, Merge & Code).