n8n Switch Node Documentation: Routing Items Correctly
This tutorial follows n8n switch node documentation to configure Mode, routing rules and Fallback Output so unmatched items are routed visibly, not silently dropped.
Checked against the cited sources on .
Prerequisites and the Goal: Routing Every Item Somewhere Visible
This tutorial follows n8n switch node documentation practices to show how to route items into the right branch of a workflow, and how to stop items that match nothing from disappearing silently. Before starting, you need an existing n8n workflow that already produces items you want to split conditionally, for example records fetched from an HTTP Request node, a trigger, or a previous transformation step. You also need a rough idea of the conditions that should separate one branch from another, such as a status field, a category value, or a numeric threshold.
The goal is simple to state but easy to get wrong: every item should land in the branch that matches its data, and any item that matches none of your rules should still be visible in the workflow, not quietly dropped. As the official documentation explains, the Switch node's default behavior for unmatched items is to ignore them, which is the exact failure mode this tutorial helps you avoid. The official Switch node documentation cited throughout this tutorial carries no version number, so the Mode and Fallback Output behavior described below reflects the current published docs and may vary slightly across n8n versions.
Sources: Switch | Nodes | n8n Docs
Configuring the n8n Switch Node: Mode, Rules and Fallback Output
Configuring the node starts with a single decision described in the n8n switch node documentation: choose the node's Mode. Rules mode lets you build condition-based routing through the editor, comparing a data type and value for each output; this suits most branching logic where conditions are static enough to express as comparisons. Expression mode instead routes items programmatically, letting you calculate the destination output with an expression, which suits cases where the destination depends on logic a simple comparison cannot capture. This tutorial focuses on Rules mode because it is where the fall-through failure described below occurs.
In Rules mode, each output route is defined by creating a routing rule: a comparison between a chosen data type and a condition, one rule per branch you want. Add one routing rule for every distinct destination your items can reach, keeping each rule specific to the branch it feeds. Writing a manual rule meant to catch everything else can quietly fail instead of catching anything, as the Expected Results and Troubleshooting sections below explain.
Setting Up Switch Node Routing
- Choose the Mode: Pick Rules mode for condition-based branches or Expression mode for programmatic routing.
- Add routing rules: Create one rule per output, comparing a data type and value for each branch you need.
- Set Fallback Output: Point unmatched items to Extra Output or Output 0 instead of leaving the default None setting.
Sources: Switch | Nodes | n8n Docs, The Switch node "fallback" trap that silently ate half my bot's messages - English 🇬🇧 - n8n Community
Expected Results When the Switch Node Is Configured Correctly
With routing rules in place and Fallback Output set to Extra Output or Output 0 rather than left on the default, items that match a rule travel to that rule's branch, and items that match none travel to the fallback branch, where you can inspect, log or alert on them. Left on the default None setting, unmatched items are simply ignored: no branch, no error, nothing downstream to catch them. A community forum report from 2026 describes exactly that gap: a Telegram-bot workflow where free-text messages matching no rule simply vanished, with no failed execution to flag the problem.
The fix reported in that same case was to stop relying on a manual rule and instead use the Switch node's built-in fallback option set to the extra-output mode, which produced an automatic extra output catching whatever the routing rules missed. Treat that as one practitioner's account rather than a guaranteed fix for every workflow, but it matches how the fallback setting is documented to behave.
Sources: Switch | Nodes | n8n Docs, The Switch node "fallback" trap that silently ate half my bot's messages - English 🇬🇧 - n8n Community
Troubleshooting: Finding Items That Vanish Without an Error
If items seem to disappear somewhere inside a Switch node and no execution fails, a common cause is the default fallback behavior, which discards unmatched items instead of raising an error. The lesson from the community report described above — checking the Fallback Output setting rather than relying on a manual catch-all rule — is a reliable first thing to check when this happens.
Two checks help confirm and fix this:
- Open the node's options and confirm Fallback Output is set to Extra Output or Output 0, not left on the default None setting.
- Review any rule written to "match everything else"; it is easy for such a rule to match nothing in practice, as the community report describes.
Sources: Switch | Nodes | n8n Docs, The Switch node "fallback" trap that silently ate half my bot's messages - English 🇬🇧 - n8n Community
Editorial Recommendations for Testing and Reviewing Switch-Based Routing
Beyond following the n8n switch node documentation step by step, one habit helps catch routing gaps before they reach production: test the Switch node with sample items expected to match each rule, plus at least one item expected to match none, and confirm that the fallback path actually fires. This is an editorial suggestion for your own review process, not a validated testing framework.
Sources: Switch | Nodes | n8n Docs, The Switch node "fallback" trap that silently ate half my bot's messages - English 🇬🇧 - n8n Community
