Question 1

Explain the difference between the IF, Switch and Filter nodes.

Accepted Answer

Build the distinction around output count — that is the clearest explanation. "IF has two outputs: matching items go out through true, the rest through false. Nothing is lost, so I use it when both cases need a reaction. Switch has several outputs, each with its own rule. It is for routing by category — three teams by ticket type, say. One Switch is both shorter and more readable than a chain of three or four IFs. Filter has one output: non-matching items are simply dropped. Ideal for cleaning junk data out, bad when you need to see what was discarded. An important nuance: all three work per item. With 50 items the condition runs 50 times and the items are split."

Question 2

A condition is not behaving as expected. How do you debug it?

Accepted Answer

Show a sequence and highlight the most frequent cause. "I look at the node's input data first, not at the condition. About three quarters of the causes are there. 1. Type. If the value shows in quotes in the node output, it is a string. APIs often return numbers as strings — "1500" and 1500 behave differently in a numeric comparison. Booleans are worse: the string "false" is non-empty and can evaluate as truthy. 2. Field presence. If the field is missing on some items, the comparison runs against undefined. "Exists" and "is not empty" are separate conditions. 3. Path. The field is nested and I am referencing the wrong path — a forgotten array index, typically. Then I simplify and re-run: keep one condition at a time until I find the broken one. Pinned data helps a lot here — I can iterate against the same input repeatedly."

Question 3

How do you keep a heavily branching workflow readable?

Accepted Answer

This is the n8n version of a code-quality question — answer it with the same principles. "I apply four rules. Node names. I never keep the defaults — not IF but IF: amount over 5000?. In a ten-node workflow that replaces half the documentation. Turning IF chains into a Switch. Whenever I see three or four IFs in a row, one Switch is almost always clearer. Extracting sub-workflows. If a branch is five or six nodes on its own and is needed elsewhere too, I make it a separate workflow — the main canvas simplifies and the logic gets reused. Sticky notes. I write down on the canvas why a complicated condition is built the way it is. Six months later that note is for me. On top of that I give every path an ending — an empty output means items vanish silently, and that is among the hardest bugs to find."

Node	Outputs	Non-matching items	When
IF	2 (true / false)	Continue down the false branch	Both cases need a reaction
Switch	One per rule (+ a fallback)	Go to the fallback output	Routing by category
Filter	1	Dropped — no trace	Cleaning junk data out

Conditions: IF, Switch and Filter

📚 Sources and documentation