Loading tutorials…
Loading tutorials…
Routers and filters are how scenarios stop being linear toy automations and start handling real-world conditionality. This is the structure that prevents 1,000-line debug sessions.
Who this is forOwners with at least one working Make scenario who need to branch logic — different actions for different conditions. Everyone who graduates past "if this then that" hits this.
What you'll need
Step 1
Filter = only some bundles pass to next module. Router = branch into multiple parallel paths. Combination = router with filters on each route.
Filter: a "checkpoint" between two modules. Bundles that meet the condition continue; others are dropped silently.
Use filter when: you only want SOME records to trigger the action. Example: "Only send email if order value > $500."
Router: a "branch" that splits the flow into multiple parallel routes. Each route has its own modules.
Use router when: different records need different actions. Example: "If country = US, send to US fulfillment. If country = EU, send to EU fulfillment. If else, send to global."
Combination: each route in a router can also have its own filter. Use when branching is complex.
Step 2
Hover the connecting line between two modules → click the wrench → Set up a filter → define conditions.
On the canvas, hover over the line between any two modules. A small wrench icon appears.
Click the wrench → "Set up a filter."
Label the filter clearly: "Only high-value orders" or "Skip test contacts."
Define the condition: pick a field from the upstream bundle, pick an operator (equal to, greater than, contains, etc.), enter the value.
Add additional conditions with AND/OR if needed. Multiple AND conditions in one filter; OR creates "any of these match" logic.
Save. Run Once to confirm filtered bundles are correctly dropped.
Step 3
Right-click any module → Add Module → Tools → Router. Then build each route independently.
On the canvas, right-click the upstream module → "Add another module."
Search "Router." Add it. The Router has multiple output dots (initially 1).
For each branch you want, hover the Router → click + on the right edge to add a new output dot.
Click each output dot and add the action modules for that branch.
On each branch line (the line between Router and the first module of that route), set up a filter — what bundles get sent down this route.
Without filters, every bundle goes down every route. That is rarely what you want.
Step 4
In Router settings, set one route as the Fallback. Bundles that match no other filter go down this route.
Right-click the Router → Settings.
For one of your routes, toggle "Fallback route" ON.
Bundles that did not match any other route's filter will flow down the fallback.
Use fallback for: catch-all error logging, default actions, "anything else" cases.
Without a fallback, unmatched bundles disappear silently — you cannot tell what was skipped.
Step 5
Run Once with sample data for each route. Verify the correct route fires and the wrong routes do not.
Add 3-5 test records to your trigger source, each matching a different branch condition.
Run Once. Check the History → drilldown into the run.
For each test record, verify it went down the EXPECTED route only. The other routes should show 0 executions for that bundle.
If a record went down a wrong route OR multiple routes, your filters are too loose or routes are configured "Match all" instead of "Match first."
Router execution mode: by default, ALL matching routes fire (parallel). To switch to "first match only," edit Router Settings.
Step 6
Filters before expensive modules save operations. Push filters as early in the flow as possible.
Operations consumption rule: every module that runs consumes ops. If a bundle is going to be filtered out, do it BEFORE the expensive modules (HTTP calls, API writes).
Example: scenario reads from Sheets (1 op) → enriches with HTTP module (1 op) → writes to HubSpot (1 op) → filter out test records.
Better: scenario reads from Sheets → filter out test records BEFORE the HTTP call → enrich only real records → write only real records. Same outcome, 30-60% fewer ops.
Audit existing scenarios with routers. For each route, ask: "Can I move this filter earlier?"
Step 7
In a doc or comment field, write out the branching tree. Future-you (or your team) will not remember the conditions in 3 months.
On the canvas, every module has a Notes field (right-click → Add Note).
On the Router, document: "Routes by country. US, EU, Rest of World."
On each route filter, document: "country == US"
Optional: in a separate Google Doc, draw the branching tree visually. Especially valuable for scenarios with 4+ routes.
6 months from now, when something needs to change, this documentation is what makes the change safe.
Common mistakes
Routes with no filter (all bundles down every route)
What goes wrong: A scenario with 4 routes and no filters processes every bundle 4 times. Operations cost 4x. Worse, downstream actions duplicate — contacts created 4 times, emails sent 4 times.
How to avoid: Every route MUST have a filter. Even the fallback route. Without filters, the Router is just multiplying ops, not branching logic.
Forgetting the Fallback route
What goes wrong: Bundles that match no filter disappear silently. You assume they were handled; they were dropped. Lost data, missed customers, no error to investigate.
How to avoid: ALWAYS set one route as Fallback (Router Settings → toggle Fallback on a route). Use it for catch-all logging or default action.
Filtering after the expensive modules
What goes wrong: Scenario calls a paid HTTP API for every bundle, then filters out 80% of bundles. You pay for 100% of API calls when 20% would have sufficed. 5x cost for nothing.
How to avoid: Push filters as early as possible. Filter BEFORE HTTP, database writes, or expensive API calls. Operations cost compounds — early filtering compounds savings.
Using nested routers when filters would suffice
What goes wrong: Scenario has a Router with 3 routes. Inside one route, another Router with 3 more routes. 9 paths total. Debugging is painful, ops cost is high, scenario becomes unmaintainable.
How to avoid: Flatten nested routers when possible. Most "nested" logic can be expressed as a single Router with more routes and tighter filters per route.
Not documenting branching conditions
What goes wrong: 6 months later, you cannot remember what each filter does. Changes break the scenario in surprising ways. Team members joining cannot maintain it.
How to avoid: Use the Notes field on every Router and every filter. Document the condition in plain English. 30 seconds of writing saves 2 hours of re-investigation.
Recap
Done — what's next
How to build your first Make.com scenario from scratch
Read the next tutorial
Hand it off
Branching logic is where DIY scenarios break down. A specialist will design the minimum branching needed, push filters early, and document everything. From $14-16/hr — most branching-redesign projects land at $200-500.
See specialist rates
A filter is a checkpoint on a single connection — bundles either pass through or are dropped. A router splits the flow into multiple parallel routes, each with its own modules. Filters are linear; routers branch.
The router itself is free (no ops). But every module executed in any route costs 1 op per bundle. So a router that fires 3 routes for 1 bundle = 3+ ops, not 1.
Yes, by default. If a bundle matches the filter on 3 routes, it goes down all 3. To make routes mutually exclusive, set Router execution mode to 'First match only' in Router Settings.
Use filters when you want to drop bundles entirely. Use if-statements (in module field values) when you want to transform values conditionally. Different purposes; not interchangeable.
5-7 routes is the practical limit before the scenario becomes hard to debug. Past that, split into multiple scenarios chained together via webhooks, or use a Data Store with lookups.
Make
You signed up for Make and the scenario builder is staring at you. This walks through one real, working scenario end-to-end — without the marketing fluff.
Make
Iterators and aggregators are how scenarios handle arrays — looping through records, batching API calls, building emails from lists. Get these wrong and one scenario can burn your entire monthly operations budget.
Make
Production scenarios will fail. APIs go down, rate limits hit, data is malformed. The question is whether your scenario recovers gracefully or silently breaks. Error handlers are the difference.
Make
Your scenario was working. Now it is failing. The diagnosis sequence specialists run is rarely random — there is a clear order that finds the root cause faster.