Why Logic and Error Handling Matter

A workflow that just moves data from A to B is fragile. Real business processes need to decide things: only notify the sales team when a deal value exceeds a threshold, only save records when required fields are present, and most importantly, keep running when something goes wrong unexpectedly. Without branching and error handling, a single bad API response can silently break your entire pipeline.

In n8n, logic and error handling are built from a small set of nodes that you combine like LEGO blocks. The IF node branches your flow. The Switch node handles multi-way routing. The Filter node removes unwanted items before they reach downstream nodes. The Stop and Error node, plus the Error Trigger workflow, give you ways to catch and respond to failures.

Branching with the IF Node

The IF node evaluates a condition against each item and sends true results down one path, false results down another. This is your primary tool for two-way decisions.

{
  "conditions": {
    "number": [
      {
        "value1": "{{ $json.amount }}",
        "operation": "larger",
        "value2": 1000
      }
    ]
  }
}

In the example above, the node checks whether the amount field on each incoming item is greater than 1000. Items that pass continue on the true branch. Items that fail drop into the false branch where you can route them to a different action, such as a Slack alert or a low-priority queue.

For more than two possible paths, use the Switch node. It works like a switch statement in code: you define rules, and the first matching rule determines which output the item takes.

Filtering Items Cleanly

Sometimes you do not need two branches. You just want to drop items that do not match a condition and keep going. The Filter node does exactly this. It sits between two nodes and silently discards items that fail the condition.

{
  "conditions": {
    "string": [
      {
        "value1": "{{ $json.status }}",
        "operation": "equals",
        "value2": "active"
      }
    ]
  }
}

Use Filter when the downstream action should only ever receive valid items. Use IF when both branches need their own follow-up logic. The distinction matters: an IF node still passes false items forward unless you explicitly stop or reroute them, while Filter removes them entirely.

Error Handling Patterns

n8n provides three layers of error handling. The first is the built-in Error Trigger node that starts a separate workflow whenever any workflow fails. The second is the Continue On Fail setting on individual nodes, which tells n8n to keep the workflow running even if that specific node errors out. The third is the Stop and Error node, which you trigger deliberately when your logic detects an impossible state.

// Pseudocode for a retry pattern using Continue On Fail + Wait
try {
  // call external API
} catch {
  // log failure
  // wait, then retry up to 3 times
}

A common pattern looks like this: wrap an HTTP Request node with Continue On Fail turned on. If the call fails, route the output through a Wait node, then back into the HTTP Request node. After three loops, branch off to an error handler that sends a notification and writes the failed payload to a dead-letter table in your database for manual review.

Practical Tips and Common Mistakes

Two mistakes come up repeatedly. First, people enable Continue On Fail on every node because they want resilience, but this hides real bugs. A 401 unauthorized response and a genuine logic bug both look the same to a downstream node that ignored the error. Be selective: only set Continue On Fail on nodes where you have a specific recovery path planned.

Second, people forget that n8n processes items one at a time within a node, but multiple items can enter a node in a single execution. Your IF conditions must work correctly for every item, not just the first one. Test with at least three varied inputs including edge cases like empty strings, zero values, and null fields.

Tổng kết

Logic in n8n is not magic; it is a small toolkit of nodes applied with intention. Use IF and Switch for explicit branching, Filter for silent cleanup, and a layered error strategy combining Continue On Fail, dedicated error workflows, and a dead-letter destination for failures you cannot auto-recover from. The workflows that survive contact with real business data are the ones that expect things to go wrong and handle it gracefully.