# Make.com Routers and Filters Explained Step by Step

*How-to — 2026-10-07 — by Mahmoud Zalt*

How Make.com routers split a scenario into branches, how filters decide which bundle goes where, and the fallback route that catches the rest.

**Short answer.** **A router splits one scenario into several routes. A filter on each route decides which data is allowed down it.** You add the router from the flow control tools, then click the line leading into each branch and set up a filter. Make processes the routes one after another in the order you set, not all at once, and one route per router can be marked as the fallback that catches whatever matched nothing else.

**About this guide.** This guide is based on publicly available information and Make's own documentation, checked on 17 August 2026. Sistava is not affiliated with Make. Interfaces and pricing change often, so confirm the current steps in their documentation before you rely on them.

Your scenario works, and then reality arrives. A high value order should go to a human. A refund request should not go to the sales channel. A form submission from an existing customer should update a record rather than create one. One straight line of modules cannot express any of that.

Make handles this with two separate ideas that beginners often merge into one. The router creates the branches. The filter decides who is allowed down each branch. They are independent, and understanding that separation is most of the battle.

## What is the difference between a router and a filter?

A router is a flow control module that branches your scenario into multiple processing chains, so the same incoming data can be handled several different ways. A filter is a condition placed on a connection between two modules, and it decides whether a bundle is allowed to continue past that point.

You can use a filter without a router. Put one on the line between any two modules and it acts as a gate: bundles that fail the condition simply stop there. That is often all a scenario needs, and it is cheaper than branching.

You reach for a router when the same event genuinely needs different downstream work. Once you have branches, each branch usually gets its own filter, which is why the two features feel like one thing in most tutorials.

## How do you add a router to a scenario?

Make's documentation gives two ways. You can click Add another module, search the Flow controls group, and choose Router. Or you can right click the connection between two existing modules and choose Add a router, which drops the router into that spot.

The router itself has almost no settings. That surprises people who expect a configuration panel with conditions in it. All of the decision making lives on the routes, not on the router.

## How do you set a filter on a route?

You click the connection leading into the branch and set up a filter there. Make's filtering documentation describes the panel as a place to enter a name for the filter and define one or more conditions, where each condition is one or two operands plus an operator that determines the relation between them.

The important habit is that operands are entered exactly the way you map any other field. You pick the value from the panel of upstream outputs rather than typing what you think it says. A typed operand is static text, and static text compared against static text is a condition that never changes its answer.

Their documentation groups the operators into basic ones, Exists and Not exists, which check whether a field is filled in at all, plus text comparison operators, numerical operators, time and date operators, and operators for working with arrays. Exists is the quiet workhorse: most broken filters are really a field that arrived empty.

### Branching a scenario with a router and filters

1. **Run the scenario once first** — Your filter needs real sample data to map operands from. Run the trigger before you build the branches so Make knows the shape of the incoming record.
2. **Insert the router** — Either add a module and pick Router from the flow control tools, or right click the connection where the split should happen and choose to add a router there.
3. **Attach the first branch** — Add the module that should handle the first case. The router creates a route to it automatically.
4. **Set the filter on that route** — Click the connection into that branch, name the filter something you will recognise in six months, then build the condition from mapped values rather than typed text.
5. **Repeat for each remaining case** — Add the next branch and its filter. Give every route a name, because an unnamed route tells you nothing when you open the scenario later.
6. **Add a fallback route** — Add one more branch for the data that matched none of your conditions, and mark it as the fallback in its filter window.
7. **Set the route order** — Open the router's context menu and choose Order routes, then arrange the branches. Make processes them in this order, so put the specific cases above the general ones.
8. **Test with an awkward record** — Feed the scenario something that should hit each branch in turn, including one record that should hit the fallback, and check the destination app rather than the run history.

If that felt like a lot of clicking to express one business rule, it is worth knowing there is another shape. At Sistava you write the rule as a sentence and the AI Employee applies it, including to the cases nobody thought to draw a branch for.

## Do the routes run at the same time?

No. Make's router documentation is explicit that routes are processed sequentially rather than simultaneously, and that Make will not process the second route until it has finished processing the first one. The parallel look of the canvas is a drawing, not a description of execution.

That matters when one branch writes something another branch reads. If route two looks up a record that route one creates, the order is doing real work for you, and a rearrangement will silently break it.

You control that order deliberately. The router's context menu has an Order routes option that opens a dialog where you rearrange the branches with arrows, and an Auto-align arranges with set order checkbox that tidies the canvas to match.

**Overlapping filters are allowed, and sometimes correct.** A bundle is not consumed by the first route that accepts it. If two routes both accept it, both run. That is useful when one event should both notify a channel and update a record, and it is a bug when you meant the branches to be exclusive. Decide which one you meant, and write conditions that say so.

## What is a fallback route and why does it matter?

A fallback route is the branch that handles data which did not fit the condition of any other route. Make's documentation describes setting one by opening a route's filter window, selecting Yes for the fallback option, and saving. The router then shows a special arrow icon marking that branch.

One fallback per router is the limit. You can still apply a filter to the fallback route itself, which is useful when you want to catch the leftovers but only some of them.

Skip this and your scenario develops a quiet habit of dropping records. Nothing errors. The run is green. The record just never arrives anywhere, and you find out weeks later from a customer. Sending the fallback to a channel you actually read is the cheapest insurance in the whole product.

## Do routers and filters cost operations?

Filters save operations rather than spend them. Make defines an operation as a single module run to process data or check for new data, and states that a module's number of operations depends on the number of bundles it processes. A bundle stopped by a filter never reaches the modules below it, so it never spends on them.

That is the practical argument for filtering as early as you can. A condition placed immediately after the trigger prevents the whole chain from running on records you were going to discard at the end anyway.

## When does a router stop being the right answer?

Routers are excellent when the branching rule is crisp and stable. Country equals one of three values. Amount above a threshold. Status field matches a known list. That kind of logic belongs on a canvas and will keep working for years.

It gets harder when the rule is a judgement. Route the angry emails to me. Escalate anything that reads like a legal threat. Those sentences have no operand and no operator, so people approximate them with keyword conditions, and then spend months adding branches for the cases the keywords missed.

Set-up work like this is exactly what we removed at Sistava. Rather than drawing the branches and maintaining the conditions, you hire an AI Employee and tell it in plain English what should happen and when. It has the tools connected already, it asks you when it is unsure, and it sets itself up. No routes to order, nothing to keep in sync.

Neither approach is a replacement for the other. Deterministic branching belongs on a router. Work where the answer depends on reading the content belongs with something that can read the content.

## What goes wrong with routers and filters?

Almost every broken branch is one of five things, and all five are visible in a single test run if you look at each module's bundle count rather than the overall green tick.

- A typed operand instead of a mapped one, so the condition compares two fixed strings and always gives the same answer.
- A field that arrives empty, which fails a text comparison in a way that looks like the filter is broken. Test with Exists first.
- No fallback route, so unmatched records disappear without any error at all.
- Route order assumed to be irrelevant, when a later branch depends on something an earlier one creates.
- Overlapping conditions, so a record quietly travels two branches and the destination gets duplicates.

**Name every route before you have five of them.** Make lets you name both filters and routes. An unnamed router with four unnamed branches is unreadable a month later, and you will end up opening each filter one at a time to remember what it does. Their documentation also notes that copying filters is not natively supported, so a clear name is cheaper than rebuilding a condition you cannot find.

## FAQ

### What is the difference between a router and a filter in Make?

A router is a flow control module that splits the scenario into several routes so the same data can be handled different ways. A filter is a condition on a single connection that decides whether a bundle continues past that point. You can use a filter on its own, without any router at all.

### Do Make router routes run at the same time?

No. Make's router documentation states that routes are processed sequentially and that the second route is not processed until the first has finished. You set the order yourself using the Order routes option in the router's context menu.

### What happens to data that matches none of my routes?

Nothing, unless you built a fallback route. Make lets you mark one route per router as the fallback, which handles data that did not fit the conditions of any other route. Without one, unmatched records stop at the router with no error raised.

### Can one bundle go down two routes at once?

Yes. Routes are not exclusive, so if a bundle satisfies the filters on two branches, both branches process it. If you need exclusive behaviour, write conditions that cannot both be true, or use the fallback route for the remainder.

### Why does my filter block everything?

Most often the operand was typed rather than mapped, or the field is genuinely empty on the incoming record. Open the run history, look at the bundle that was stopped, and check the actual value the filter received rather than the value you expected.

### Do filters cost operations in Make?

Make counts an operation as a module run, and a module's operations depend on how many bundles it processes. A filter that stops a bundle prevents the modules below it from processing that bundle, so filtering early reduces usage rather than adding to it.

## Sources

- [Make Help Center, Router](https://help.make.com/router), for route order, the Order routes dialog, and fallback routes.
- [Make Help Center, Filtering](https://help.make.com/filtering), for how conditions, operands, and operators are defined.
- [Make Help Center, Operations](https://help.make.com/operations), for how module runs and bundles map to operations.
- [Make Help Center, Scenario execution flow](https://help.make.com/scenario-execution-flow), for how bundles travel between modules.
- [Bannerbear, Routers and filters on Make](https://www.bannerbear.com/blog/routers-filters-how-to-process-your-data-conditionally-on-make/), an independent walkthrough including the one fallback per router limit.
- [GrowwStacks, How to use Router in Make](https://growwstacks.com/blog/how-to-use-router-in-make-com), for practical route naming and testing advice.

**Tags:** make-com, automation, no-code, workflow-automation, conditional-logic