n8n Filter Node: Route Workflow Items Without Losing the Good Ones

The n8n Filter node is the simplest way to stop the wrong items from moving through a workflow. It checks each incoming item against one or more conditions. Items that match continue. Items that do not match are omitted from the Filter output, so downstream steps only handle the records they are meant to process.

That sounds basic, but it is one of the most important production safeguards in n8n. A weak filter sends unpaid orders to fulfillment, empty emails to outreach, low-quality leads to sales, or bad payloads into a database. A good filter makes the rule explicit before the workflow spends API calls, updates a CRM, or alerts a team.

Quick answer: what does the Filter node do?

The Filter node keeps items that meet a condition and drops items that do not. Conditions can use data types such as string, number, date and time, boolean, array, and object. You can add multiple conditions and choose whether an item must meet all of them with AND logic or any of them with OR logic.

Use it when the workflow already has data and needs a gate: only paid orders, only tickets with a priority, only leads with an email, only invoices over a threshold, only rows updated after a date, or only payloads where a required field exists.

Filter node versus IF node

Use the Filter node when you only need the matching items to continue along one path. It is best for cleanup, validation, and narrowing a data set before the next node. Use the IF node when you need two visible branches: one for true items and one for false items.

A common pattern is to use Filter early to remove obvious noise, then use IF later when non-matches deserve a separate action. For example, Filter can keep only rows where email exists and status is paid. An IF node can later split enterprise leads from self-serve leads because both paths need different handling.

Choose the right condition type

The condition type matters because n8n compares values differently depending on whether they are strings, numbers, dates, booleans, arrays, or objects. If a total arrives as text but you compare it as a number, the workflow can fail or behave differently than expected.

• Use string conditions for fields such as email, status, source, name, domain, and message text.
• Use number conditions for totals, scores, counts, quantities, and thresholds.
• Use date and time conditions for created_at, updated_at, due dates, booking times, and expiry checks.
• Use boolean conditions for explicit true or false fields such as approved, active, paid, or has_attachment.
• Use array and object conditions to check whether structured payloads exist, are empty, or contain expected data.

AND versus OR rules

AND means every condition must be true. Use it when each requirement is mandatory. A lead workflow might require email exists, company size is greater than 10, and source is not empty before sending the record to sales.

OR means any condition can be true. Use it when several signals should qualify an item. A support workflow might continue if priority is high, customer plan is enterprise, or message contains outage. n8n does not let one Filter node mix AND and OR groups, so split complex logic into separate nodes when the rule needs both.

Set the failure path before you need it

The Filter node omits items that do not match. That is useful, but it can hide important misses if you never inspect them. In production workflows, decide what should happen to dropped items before the workflow goes live.

If non-matches are harmless noise, dropping them is fine. If they are incomplete orders, unqualified leads, or payloads that might indicate a broken integration, send a copy to a review path before filtering or use an IF node when you need a false branch.

Use less strict type validation carefully

n8n includes a Less Strict Type Validation option that can help when a value arrives in the wrong type, such as a number stored as a string. It is useful for reducing workflow friction, but do not use it to hide messy upstream data forever.

For safer workflows, normalize important values before the filter. Convert totals to numbers, normalize email casing, trim whitespace, and map empty values into a consistent shape. Then the filter becomes a business rule instead of a guess about incoming data.

Practical Filter node recipes

For order automation, filter to status is paid and total is greater than zero before fulfillment, accounting, or customer messaging. Add a review path for paid orders missing an email or address.

For lead routing, filter to email exists, company domain is not empty, and source is not internal testing. Then score or enrich only the records that can actually become useful opportunities.

For support triage, filter messages where priority is high, sentiment is negative, or customer plan is enterprise. Use OR logic when any one urgent signal should pass the item forward.

For document workflows, filter files where mime type is PDF or CSV before extraction. That avoids sending images, folders, or unsupported attachments into parsing nodes that expect a specific format.

Common mistakes

• Filtering on display text instead of a stable status, ID, or normalized field.
• Using AND when the workflow needs OR logic, which drops valid edge cases.
• Using OR when every requirement should be mandatory, which lets weak records through.
• Forgetting that non-matching items are omitted from the Filter output.
• Relying on less strict validation instead of cleaning the data shape upstream.

Where Synta helps

Synta is useful when the filter rule is clear in plain English but annoying to wire correctly. Describe the source data, which records should continue, which records should go to review, and what should happen when a field is missing or typed incorrectly.

That gives the generated n8n workflow a reviewable shape: normalize values, filter safely, preserve the records that need manual review, and continue only with items that are ready for the next action.

Try the Synta MCP workflow builder

If you are building a filter-heavy workflow in n8n, use the tracked Synta MCP path here: open Synta MCP. Describe the keep rule, the review rule, and the fields that must be normalized before the Filter node runs.

FAQ

Does the Filter node have a false output?

No. The Filter node passes matching items to its output and omits non-matching items. Use the IF node when you need separate true and false branches.

Can I combine multiple conditions?

Yes. You can add multiple conditions and choose AND when all conditions must match or OR when any condition can match. For mixed AND and OR logic, split the rule across multiple nodes.

What should I do with dropped items?

If dropped items might matter, copy them to a review path before filtering or use an IF node so the false branch can log, alert, or route them.

Why does my Filter node complain about the wrong type?

The incoming value may be a string, number, date, boolean, array, or object that does not match the comparison type. Normalize the field before the Filter node, or use less strict type validation only when that conversion is intentional.