node cookbook
n8n IF Node: Branching Patterns, Common Mistakes, and Expression Errors
Use the IF node when a workflow needs to branch based on conditions, such as status, field values, dates, numbers, or whether data exists.
Match your incident first
Start with the symptom you can prove
Referenced node did not execute
First check: Open the failed execution and inspect which branch produced the current item.
Wrong fix to avoid: Do not add dummy Set nodes just to silence the error without fixing data flow.
Verify: The expression handles both branch outcomes or references only nodes guaranteed to run.
Field is missing on some items
First check: Pin or inspect multiple real items, not only the first successful item.
Wrong fix to avoid: Do not hardcode array indexes before checking all item shapes.
Verify: The expression uses safe access/defaults and succeeds for empty, partial, and normal items.
Expression works in manual test but fails in production
First check: Compare pinned test data with a recent production execution payload.
Wrong fix to avoid: Do not rely on pinned data as proof of production behavior.
Verify: A fresh production execution with live data passes the same expression.
- Use when
- n8n workflows, branching, logic
- First check
- Place the IF node after the node that creates or retrieves the value to test.
- Time to check
- 5-10 minutes
- Next step
- Run the recommended steps, then verify a production execution.
Independent third-party notes. n8n is a trademark of its owner and is referenced only for compatibility and troubleshooting context.
Quick Answer
Use the IF node when a workflow needs to branch based on conditions, such as status, field values, dates, numbers, or whether data exists.
Problem Pattern
The user knows they need branching, but the real risk is data shape, type comparison, and downstream nodes referencing the wrong branch.
Version awareness
Last reviewed 2026-05-21
Key Facts
- Node role
- Route items down true or false branches based on conditions.
- Best fit
- Simple workflow branching and validation checks.
- Common inputs
- Fields, expressions, booleans, dates, numbers, strings, and existence checks.
- Common companion nodes
- Merge, Set, Code, Webhook, Schedule Trigger, and app nodes.
Production Diagnostic Matrix
Turn checks into a brief| Exact symptom or log | Likely cause | First check | Wrong fix to avoid | Verification |
|---|---|---|---|---|
| Referenced node did not execute | Expression reads from a node on a branch that did not run for this item. | Open the failed execution and inspect which branch produced the current item. | Do not add dummy Set nodes just to silence the error without fixing data flow. | The expression handles both branch outcomes or references only nodes guaranteed to run. |
| Field is missing on some items | Input items have inconsistent shape, optional provider fields, or previous node output changed. | Pin or inspect multiple real items, not only the first successful item. | Do not hardcode array indexes before checking all item shapes. | The expression uses safe access/defaults and succeeds for empty, partial, and normal items. |
| Expression works in manual test but fails in production | Manual pinned data differs from live payload, timezone, credentials, or branch timing. | Compare pinned test data with a recent production execution payload. | Do not rely on pinned data as proof of production behavior. | A fresh production execution with live data passes the same expression. |
| Invalid JSON from HTTP Request or Set node | String interpolation produced invalid quoting, trailing commas, or unescaped newlines. | Validate the exact body sent by the node, not the visual expression preview only. | Do not wrap an already-object value in extra quotes. | The downstream node receives valid JSON and the response status is expected. |
| IF branch changes data shape | True and false outputs carry different fields, item counts, or nested paths. | Inspect both IF outputs and define a shared normalized shape before merge/response. | Do not assume the true branch schema exists on false branch items. | Both branches feed the next node with the same required fields. |
| Code node returns wrong item format | Code returns a raw object/array instead of an array of items with json fields. | Check the Code node return value against the required item format. | Do not return secrets or full credentials for debugging. | The next node receives items shaped like [{ json: {...} }]. |
Recommended Steps
- Place the IF node after the node that creates or retrieves the value to test.
- Choose the condition type that matches the data shape.
- Map or write the left-side value using a field or expression.
- Set the comparison value or existence rule.
- Test both true and false branches with representative data.
Verification
- Known true examples go to the true branch.
- Known false examples go to the false branch.
- Downstream nodes do not reference data that is unavailable on the chosen branch.
Warnings
- A branch can fail later if it references data from a node that did not execute on that path.
- String, number, boolean, and date comparisons can behave differently if incoming data is not normalized.
Common Mistakes
- Comparing a number stored as text without normalizing it.
- Expecting both branches to run for each item.
- Referencing a node from the other branch later in the workflow.
- Using a complex IF condition where a Code node would be clearer.
Examples
If lead.score >= 80:
true branch -> notify sales in Slack
false branch -> append to nurture sheetFAQ
Should I use IF or Switch?
Use IF for a two-way true/false split. Use Switch-style routing when you need several named branches.
Why does a downstream expression fail after IF?
That branch may not have executed the node being referenced, or the item shape differs between branches.