n8n IF Node Explained: Add Conditional Logic to Your Workflows (2025)

The n8n IF node is how you add conditional logic to a workflow — it splits your data into two paths, true and false, based on rules you define. If you've ever wanted a workflow that only sends an alert when a deal has gone quiet, or only creates a task when an amount crosses a threshold, the IF node is the tool. This guide explains how the IF node works, the condition types it supports, how to combine rules with AND/OR, how to compare dates for "older than X days" logic, and when to reach for Switch or Filter instead.

What the IF node does

The IF node evaluates one or more conditions against each incoming item and routes that item to one of two outputs. In the n8n editor the node shows two connectors on its right side: the top output is true and the bottom is false. Items that satisfy every condition (under AND) go true; everything else goes false.

This matters because the IF node runs per item. If ten items arrive, each is tested individually — some may go true and some false. Downstream nodes on the true branch only ever see the items that passed. That's what makes IF the backbone of any "only act when…" automation.

Reading the two outputs

A common mistake is leaving the false branch unconnected and assuming those items just disappear. They don't error, but if you never wire up the false output, those items simply stop there. That's often fine — for an alerting workflow you usually only care about the true path. Just be deliberate about it so you know where every item ends up.

Condition types

When you add a condition in the IF node, you first pick a data type for the comparison. Choosing the right type is important because n8n compares values differently depending on it. The main types are:

  • String — text comparisons: equals, not equals, contains, starts with, ends with, matches regex, is empty. Use for statuses, names, email addresses, stage labels.
  • Number — numeric comparisons: equals, greater than, less than, greater or equal, less or equal. Use for amounts, counts, scores, quantities.
  • Boolean — true/false checks. Use for flags like is_active or a field that already holds a boolean.
  • Date & Time — chronological comparisons: is before, is after, is equal to. Use for timestamps like "last activity date" or "created at".
  • Array / Object — checks like "contains" or "is empty" against list and object fields.

Each condition has three parts: a left value (usually an expression pulling a field from the incoming data), an operator, and a right value (the thing you compare against). The left value is almost always an expression such as {{ $json.status }}, while the right value can be a fixed value you type in or another expression.

A simple example

Say each item represents a deal and has a field amount. To route high-value deals down the true branch, you add one Number condition:

Left value:  {{ $json.amount }}
Operator:    is greater than
Right value: 5000

Deals over 5000 go true; everything else goes false. Wire a Slack node to the true output and you have a high-value-deal alert.

Combining multiple conditions with AND / OR

Real rules are rarely a single test. The IF node lets you add several conditions and choose how they combine:

  • AND — the item goes true only if every condition passes. Use this to narrow: "amount over 5000 AND stage is not closed AND owner is not empty."
  • OR — the item goes true if any condition passes. Use this to widen: "priority is high OR amount is over 10000."

You set the combinator once for the group of conditions. For most operational workflows you'll use AND to build a precise filter — you want the alert to fire only when a specific set of circumstances all line up. Reach for OR when several different triggers should produce the same action.

If you need genuinely nested logic — "(A AND B) OR (C AND D)" — a single IF node can't express that directly. The clean pattern is to chain IF nodes, or compute a boolean in a preceding Code or Set node and test that single flag in the IF.

Comparing dates: "older than X days" logic

Date conditions are where the IF node earns its keep in real automations. The classic use case is flagging records that have been untouched for a while: a deal with no activity in 7 days, an invoice unpaid for 30, a ticket with no reply in 48 hours.

The pattern is to compare a stored timestamp against "now minus N days." In an expression you can build the cutoff with n8n's built-in Luxon date support. For example, to test whether a deal's last activity is older than 7 days, use a Date & Time condition like this:

Left value:  {{ $json.last_activity_date }}
Operator:    is before
Right value: {{ $now.minus({ days: 7 }).toISO() }}

Here $now is the current time and .minus({ days: 7 }) subtracts seven days. Any deal whose last activity is before that cutoff — meaning nothing has happened in over a week — goes down the true branch. That's exactly the logic behind a stuck-deals alert: the IF node quietly scans every open deal each morning and only lets the stale ones through.

A few tips for date conditions: make sure both sides are actual dates, not strings that merely look like dates — wrap the field in toDateTime() if it arrives as text. And be mindful of time zones; storing and comparing everything in ISO/UTC avoids off-by-a-day surprises.

Want this working without building it from scratch? The Stuck Pipedrive Deals → Daily Slack Alert + Task template uses exactly this date-condition pattern to catch deals with no activity for N days and ping your team every morning. Get the Stuck Pipedrive Deals → Daily Slack Alert + Task template →

IF vs Switch vs Filter

The IF node isn't the only way to branch, and picking the right node keeps workflows readable.

NodeOutputsUse when
IFTwo (true / false)A single yes/no decision. "Is this deal stale or not?"
SwitchMany (one per rule)Routing into three or more paths. "Send to sales, support, or billing based on category."
FilterOne (only passing items)You want to drop items that fail and keep only those that pass — no false branch needed.

Rule of thumb: use Filter when you're removing items and don't care about the ones that fail. Use IF when both outcomes need to do something, or when you want to keep a two-way structure clear. Use Switch the moment you have more than two destinations — chaining a pile of IF nodes to fake multi-way routing gets messy fast.

A practical branching example

Imagine processing incoming deals. First an IF checks whether the deal is stale (older than 7 days). On the true branch, a Switch could then route by deal size — small, medium, enterprise — each triggering a differently worded Slack message and a task for the right owner. IF handles the yes/no gate; Switch handles the multi-way sort. That division of labor keeps the canvas legible.

Common pitfalls

  • Wrong data type. Comparing a number as a string can give surprising results (string "9" vs "10"). Match the condition type to the actual data.
  • Empty fields. If a field is missing, a condition may not behave as you expect. Add an explicit "is empty" check when a field is optional.
  • Forgetting per-item behavior. The IF tests each item separately. If you expected one decision for a whole batch, aggregate first or rethink the flow.
  • Unhandled false branch. Decide on purpose whether false-branch items should stop, be logged, or take an alternate action.

Frequently Asked Questions

What's the difference between the IF node and the Filter node in n8n?

Both evaluate conditions, but the IF node has two outputs — true and false — so you can act on both results. The Filter node has a single output and simply passes items that meet the conditions while discarding the rest. Use IF when both outcomes matter; use Filter when you only want to keep the matching items.

How do I check if a date is older than a certain number of days?

Add a Date & Time condition, set the left value to your stored timestamp, choose the "is before" operator, and set the right value to an expression like {{ $now.minus({ days: 7 }).toISO() }}. Items whose date falls before that cutoff — meaning they haven't changed in over seven days — go down the true branch.

Can one IF node handle multiple conditions?

Yes. Add as many conditions as you need and pick a combinator: AND makes the item go true only when every condition passes, while OR makes it go true when any single condition passes. For nested logic like "(A AND B) OR C," chain IF nodes or compute a boolean in a Set/Code node first, then test that flag.

Ready to automate?

Skip the setup and start with a proven build. The Stuck Pipedrive Deals template combines IF date conditions, a Slack alert, and automatic task creation so no deal slips through the cracks. Get this template on Gumroad →