Your first automation is usually a straight line. Something happens in one app, something else happens in another app, done. And straight lines are great, right up until real life shows up with its exceptions. You do not want every email creating a task, just the important ones. You do not want every form submission treated the same, because a complaint and a compliment deserve different handling.
This is the moment every beginner meets filters and routers, the two tools that give a Make.com scenario something resembling judgment. They sound technical. They are not. One is a gatekeeper, the other is a fork in the road, and once you have those two pictures in your head, you will never confuse them again.
If you are still getting comfortable with scenarios and modules themselves, our plain-language introduction to Make.com is the best place to start before this one.
What Is a Filter, Really?
A filter is a gatekeeper standing between two modules. It holds a clipboard with one rule on it, and it asks every piece of data the same question: do you meet the condition? If yes, walk through. If no, stop right here.
Think of a nightclub bouncer with a guest list. The bouncer does not redirect people to a different club, does not take names, does not argue. People on the list go in. Everyone else simply does not. That is a filter's entire personality.
In practice, a filter condition looks like a small sentence you assemble from dropdowns:
- Subject line contains "invoice"
- Email sender equals a specific client's address
- Order total is greater than some amount you choose
- A spreadsheet's status column is empty
Two things make filters especially lovable for beginners. First, when data fails a filter, nothing bad happens. No error, no warning, no cleanup. The item just stops, politely. Second, filters are free: they are not modules, so they do not consume operations. Placing a filter early in a scenario means irrelevant data never reaches the modules that do cost something, which is the single easiest way to make a scenario cheaper to run. We cover that money-saving angle in depth in our guide to Make.com operations and the free plan.
What Is a Router, Really?
A router is a fork in the road. Where a filter asks "do you continue, yes or no?", a router says "there are several roads ahead, let us figure out which ones you travel."
The everyday picture is a mail sorting room. Letters come in through one slot, and a sorter directs them into labeled bins: bills here, personal letters there, junk in the recycling. One incoming stream, several destinations, each destination handled differently afterward.
In Make.com, you drop a router module into your scenario, and it sprouts multiple branches. Here is the detail that surprises people: the router itself does not decide anything. When data arrives, the router sends a copy down every branch. The deciding is done by a filter placed at the start of each branch. Branch one has a filter that says "only complaints continue here." Branch two says "only billing questions continue here." The router provides the roads, the filters act as the gatekeepers on each road.
So filters and routers are not rivals. A router is really a bundle of paths, each guarded by its own filter. Learn filters first, and routers come almost for free.
When Should You Use a Filter, and When a Router?
Here is the honest, practical rule:
- Use a filter alone when there is one path and you just need a rule about who gets to travel it. "Create a task, but only for emails from my boss." One road, one bouncer.
- Use a router when different kinds of data deserve genuinely different treatment, with different modules doing different work. "Complaints go to the urgent channel, invoices go to the bookkeeping folder, everything else gets a polite auto-acknowledgment." Several roads, each with its own bouncer and its own destination.
A quick self-test that works nearly every time: listen to how you describe the goal out loud. If you hear yourself saying "only if" or "but not when," you want a filter. If you hear "this kind goes here, that kind goes there," you want a router.
One more beginner tip: do not reach for a router speculatively. If today you only need one path, build one path with a filter. Adding a router later, when a real second path shows up, takes about a minute. Unused branches just sit there confusing future you.
How Does This Look in a Real Example?
Let us build the classic one, on paper: a small business inbox where support emails should be sorted by topic. The goal is that billing questions, urgent complaints, and general questions each get handled appropriately, without a human playing traffic cop all day.
The scenario shape:
- Trigger: a new email arrives in the support inbox.
- Router: the flow splits into three branches.
- Branch one, billing. Filter: subject or body contains words like "invoice," "payment," or "refund." Action: forward the email to the bookkeeper and add a row to a billing questions spreadsheet.
- Branch two, urgent. Filter: text contains words like "urgent," "broken," or "not working." Action: send an instant notification to your phone or team chat so a human sees it fast.
- Branch three, everything else. This is the fallback path for anything that did not match the first two branches. Action: file the email in a general queue to be answered in the normal daily batch.
Walk one email through it mentally. A message arrives with "refund for last month's invoice" in the subject. The router offers it to all three branches. The billing filter says yes, come through, and the bookkeeper gets it. The urgent filter says no, and that copy stops harmlessly. The fallback catches nothing extra because the email already matched a specific branch, assuming you set the fallback to act only as the last resort, which Make lets you do.
Keyword matching is not perfect, and it is worth saying so. Someone will eventually write "the thing I paid for is broken," which matches two branches at once. That is fine. Start with simple keywords, watch how real emails flow for a week in the scenario history, and adjust the conditions. Automation rules are meant to be tuned, not carved in stone.
What Should You Practice First?
If you want to feel these concepts in your hands rather than your head, take any straight-line scenario you already have, or build the simple email-to-task flow from our first Make.com automation walkthrough, and add a single filter to it. Only emails from one sender, or only messages containing one keyword. Run it, watch some items pass and others stop, and check the run history to see the filter doing its job.
Once that feels natural, add a router with two branches to the same scenario. That one exercise, filter first, router second, teaches you more than any amount of reading, and it is the foundation for nearly every clever automation you will ever build.
Next step: Ready to put gatekeepers and forks to work in real projects? The automation hub has step-by-step builds where filters and routers show up again and again.
