The If Node
Splits into two branches, true or false, based on a condition.
What it actually does
The IF node checks every item against a condition, then sends it down one of two paths: “true” if it matches, “false” if it doesn’t. It’s the node you reach for whenever your workflow needs to behave differently depending on the data — only email customers with an order over £50, only process files with a certain extension, that kind of thing.
You can compare strings, numbers, dates, or booleans, and n8n gives you the matching set of operators for whichever type you’ve picked — things like “equals,” “contains,” or “is after” for dates. If you need more than one condition, you can chain several together and combine them with AND (all conditions must match) or OR (any one will do).
Downstream, the node has two outputs — true and false — and you connect whatever should happen next to whichever branch makes sense. Items that don’t match the condition don’t vanish; they still come out, just on the other branch.
A worked example
The video builds a real order-routing example: a workflow sets fields for customer name, order value, and priority, then an IF node checks whether priority equals 1. Orders that match go down the true branch to priority processing; everything else goes down false to standard processing.
From there it adds a second condition — order value is greater than 50 — combined with AND, so only priority orders over £50 count as true. Switching that same combinator to OR changes the meaning entirely: now priority 1 orders or big orders both count, even ones that wouldn’t have matched under AND.
A third condition adds a text check — customer name contains "Farms" — with the Ignore Case option switched on. That means “Farms” and “farms” are treated as the same match; switch Ignore Case off, and suddenly they’re not, even though nothing else about the data changed.
The mistake almost everyone makes first
Comparing values as different data types — a text field against a number, say. This doesn’t fail silently: n8n throws an explicit “Wrong type” error and the run stops.
It usually happens when a field that looks numeric (an order ID, a priority level, a price pulled from a form) actually arrives as a string. The fix is to check the data type of the field you’re comparing before trusting it, or — if it genuinely doesn’t matter which type you get — enable “Convert types where required” in the node’s options.