Make.com Routers and Filters: Build Conditional Logic in Scenarios
Most Make.com scenarios work fine as a straight line: trigger → action → action. But real automation breaks down the moment you need to handle more than one outcome. A lead arrives from LinkedIn — that's a different workflow than one from your contact form. An order is marked "refunded" — that's not the same path as "fulfilled".
Make.com Routers and Filters are the mechanism for adding conditional logic to your scenarios. A Router splits execution into multiple parallel branches. A Filter controls whether a branch runs at all. Together they replace manual if-else thinking with explicit, visual decision trees.
What Is a Router in Make.com?
A Router is a special module that splits a single scenario path into two or more independent branches. Every branch can have its own chain of actions. When the scenario executes, all branches are evaluated — the Router itself does not choose one over the other. That's the job of the filters you attach to each branch.
Key behavior:
- Branches execute in the order they are listed (top to bottom by default).
- Without filters, all branches run for every execution.
- With filters, a branch only runs if its filter condition evaluates to
true. - Multiple branches can pass their filters and execute in the same run (processed sequentially, one after another).
To add a Router to an existing scenario:
- Click the + icon on any module's output path.
- Search for "Router" in the module list and select it.
- The module splits into two output paths. Add more by clicking the
+next to any existing branch.
What Is a Filter in Make.com?
A Filter is a condition you attach between two modules. It acts as a gate: the next module only runs if the condition is true. In the context of a Router, you place a filter on each branch to determine which branch executes.
To add a filter:
- Click the wrench icon (or the connector line) between two modules.
- Select "Set up a filter".
- Define a label (name it something meaningful, e.g., "Lead source = Email"), select the field to check, choose an operator, and enter the comparison value.
Filter Operators
Make.com supports a comprehensive set of operators:
| Operator | Use Case |
|---|---|
| Equal to / Not equal to | Exact string or number match |
| Greater than / Less than | Numeric comparisons |
| Contains / Does not contain | Substring checks |
| Starts with / Ends with | Prefix/suffix matching |
| Exists / Does not exist | Null / empty field checks |
| Matches pattern | Regex-based matching |
You can apply filters on any mapped field from a previous module — form fields, webhook payload properties, API response values, or Make's built-in variables.
Building If-Else Logic with a Fallback Route
The closest equivalent to an if-else statement in Make.com is a Router with two branches: one with a filter (the if) and one set as the fallback route (the else).
A fallback route runs when no other route in that Router has executed. It is not a duplicate of a filter — it is a catch-all that activates only after all other branches have been skipped.
To set a fallback route:
- Right-click on the filter icon (wrench) on the branch you want to use as the fallback.
- Check the "Fallback route" checkbox.
- The filter icon changes to indicate it is the fallback — you do not define filter conditions for it.
Example: webhook-based lead routing
Webhook (new lead arrives)
└── Router
├── Branch 1: Filter = "source = email" → Add to Email CRM
└── Branch 2: Fallback route → Add to General Queue
Branch 1 executes only when the source field equals "email". Every other lead — regardless of source — falls through to Branch 2. This is the canonical Make.com if-else pattern.
Combining AND / OR Conditions
Single conditions cover simple cases. Real scenarios require compound logic.
AND Conditions (All must be true)
Click "Add AND rule" within a filter. Every rule in the group must evaluate to true for the filter to pass.
Example: Only route to "High-Value Leads" when both conditions hold:
deal_valueis greater than5000lead_stageequals"qualified"
Both conditions must pass. If either is false, the branch is skipped.
OR Conditions (Any must be true)
Click "Add OR rule" to add a separate condition group. If any group evaluates to true, the filter passes.
Example: Route to "Social Leads" when the source is LinkedIn or Twitter:
- Group 1:
sourceequals"linkedin" - Group 2:
sourceequals"twitter"
If the lead comes from either platform, the branch executes.
Combining AND + OR
You can nest AND rules within each OR group. Use this for complex conditions like:
- Group 1:
source = "linkedin"ANDdeal_value > 1000 - Group 2:
source = "twitter"ANDdeal_value > 500
This passes leads from LinkedIn worth over $1,000 or Twitter leads worth over $500 — all others are skipped.
Practical Example: Lead Routing by Source
Here is a complete practical scenario covering the writing prompt from the issue brief: incoming leads routed by source (email, social, or web form) with different processing per route.
Scenario: New Lead from Typeform → Route by Source → CRM Action
Typeform (Watch Responses)
└── Router
├── Branch 1: source = "email" (email campaign)
│ └── HubSpot: Create Contact (list = "Email Nurture")
│ └── Gmail: Send welcome email
│
├── Branch 2: source = "linkedin" OR source = "twitter"
│ └── HubSpot: Create Contact (list = "Social Leads")
│ └── Slack: Notify sales rep
│
└── Branch 3: Fallback route
└── HubSpot: Create Contact (list = "Inbound Web")
└── Add to general drip sequence
Setup steps:
- Add the Typeform > Watch Responses trigger.
- Add a Router after the trigger.
- Branch 1: Add a filter —
{{source}}equals"email"— then chain HubSpot + Gmail. - Branch 2: Add a filter with two OR groups —
{{source}}equals"linkedin"/{{source}}equals"twitter"— then chain HubSpot + Slack. - Branch 3: Set as the fallback route. No filter needed. Chain HubSpot + drip sequence enrollment.
Every new Typeform submission runs through the Router. Exactly one branch fires based on the source value (Branch 1 or 2 if matched, otherwise the fallback Branch 3).
Nesting Routers for Complex Decision Trees
A single Router handles one decision axis. For multi-level logic (e.g., route by source, then route by deal size), nest a second Router inside a branch.
Example: Route by source, then by deal size
Webhook
└── Router (Level 1: by source)
├── Branch 1: source = "enterprise"
│ └── Router (Level 2: by deal size)
│ ├── Branch A: deal_value > 50000 → Assign to VP Sales
│ └── Branch B: Fallback → Assign to Account Exec
│
└── Branch 2: Fallback
└── Add to SMB pipeline
Nesting is valid to any depth, but keep decision trees shallow when possible. Scenarios with 3+ nesting levels become hard to debug. Consider using a Text Aggregator or Set Variable module to pre-compute a derived field (e.g., a lead_tier string) before the Router — this collapses multi-axis decisions into a single filter field.
Execution Order and Parallel Branch Behavior
Make.com processes Router branches sequentially, not in parallel. Branch 1 fully completes before Branch 2 starts. If Branch 1 contains a slow API call, Branch 2 waits.
This has two practical implications:
- Error isolation: If Branch 1 throws an error, Make.com (by default) stops execution and does not run Branch 2. Enable "Error handling" routes or use the "Resume" directive to change this.
- Multiple branches can fire: If two branches both pass their filters, both execute. This is not a bug — it is intended behavior. A lead can simultaneously trigger "Add to CRM" and "Send Slack notification" if both filter conditions are met by the same data.
If you need exactly one branch to fire (mutual exclusion), use specific filters on all branches and a fallback route, ensuring the conditions are exhaustive and non-overlapping.
Common Mistakes
Mistake 1: Using a fallback route as a "catch errors" branch. The fallback runs when no other branch passes its filter, not when an upstream module fails. For error handling, use Make.com's dedicated error handler routes (right-click any module → "Add error handler").
Mistake 2: Leaving branches without filters. A branch with no filter always runs. If you add a Router but forget to set filters on the branches, every branch fires every time — equivalent to duplicating all downstream actions.
Mistake 3: Overlapping filter conditions.
If Branch 1 filters on deal_value > 1000 and Branch 2 filters on deal_value > 500, a lead with a $2,000 deal passes both filters and both branches execute. This is often unintended. Tighten your ranges (e.g., > 1000 and > 500 AND < 1000) or use a fallback route for the lower tier.
Mistake 4: Nesting too deep. Three or more nested Routers create scenarios that are impossible to audit. Flatten the logic by computing a derived classification field in an earlier module.
FAQ
How do I add conditions in Make.com?
Use a Filter between any two modules. Click the wrench icon on the connector between them, set up a filter label, choose the field to evaluate, select an operator (equals, contains, greater than, etc.), and enter the comparison value. Filters can be placed on individual module connectors or on Router branches. Filters with multiple conditions use AND (all must pass) or OR (any group must pass) logic.
What is a Router in Make.com?
A Router is a built-in Make.com module that splits a scenario into two or more independent branches. Each branch can have its own sequence of modules. You add filters to branches to control which ones execute. Without filters, all branches run for every execution. The Router is Make.com's equivalent of an if-else or switch statement in code.
What is a fallback route?
A fallback route is a special Router branch that runs only when no other branch in the same Router has executed. It is the catch-all "else" case. Enable it by right-clicking the filter icon on a branch and checking "Fallback route". You do not configure filter conditions for the fallback — it is triggered automatically when all other branches are skipped.
Can multiple branches run at the same time?
Yes. Make.com runs Router branches sequentially (one after another), but multiple branches can pass their filter conditions in the same execution. If two branches have non-exclusive filters and both conditions are true for a given data bundle, both branches execute. To ensure mutual exclusion, design your filters to be non-overlapping and use a fallback route as the final catch-all.
What's the difference between a filter on a module and a filter on a Router branch?
They work identically — both are conditions that must be true for the next module to execute. The difference is context: a filter on a standalone module connector blocks that specific module. A filter on a Router branch blocks the entire branch, including all modules downstream in that branch.
How do I combine AND and OR conditions in a Make.com filter?
Within the filter editor, click "Add AND rule" to add a second condition that must also be true. Click "Add OR rule" to add a separate condition group — if any OR group evaluates to true, the entire filter passes. You can combine AND rules within each OR group for compound conditions.
Sign up for Make.com to start building conditional scenarios. The free tier supports up to 1,000 operations per month — enough to prototype any routing logic described in this guide.
For pulling external data into your Make scenarios — web scraping, SERP data, or social media feeds — Apify connects directly via webhook or HTTP module and works cleanly as a Router trigger source.
