3.3Filters, routers & conditional logic
The essentials in 30 seconds
- The filter sorts: a yes/no gate — the scenario only continues if the condition is true, otherwise it stops there.
- The router directs: routing to branch A, B or C by data (Make router, Zapier “Paths”).
- Filter early: placed just after the trigger, the filter avoids useless actions and saves operations.
Running case — Lina sorts requests by subject
Lina, digitalisation officer in Oran, sees her scenario process every form response, including off-topic messages that waste operations. She adds a filter just after the trigger: continue only if the subject contains QUOTE. Then a two-branch router: “business” requests go to the sales team with an alert, “individual” requests get an automatic reply. Her dumb pipe becomes a decision tree.
This same case returns in the lesson, the diagram, the script and the 48h challenge.
1. Filter and router: sort then direct
A useful automation is rarely “everything, all the time”. The filter only lets through what meets a condition (“continue only if the subject contains QUOTE”, “only if the amount is filled in”). Placed early, just after the trigger, it avoids useless actions and saves operations.
The router (Make) or paths (Zapier “Paths”) create branches: depending on a condition, the scenario takes path A, B or C, each with its own actions. Lina uses it to separate “business” and “individual”.
2. A decision tree that follows your rules
It is the “if… then… else…” logic applied to your processes: an urgent request triggers an alert, a normal request a simple row in a table; a high amount triggers an approval, a small amount a simple record.
Filters and routers turn a dumb pipe into a decision tree that reproduces your business rules. That is often what distinguishes a gadget automation from a truly reliable, adopted automation.
🔎 Concrete example — Two branches by request type
Lina reacts differently by case.
Filter: continue if subject contains QUOTE
Router:
Branch A (business) → alert + sales handover
Branch B (individual) → automatic reply + recordReading: the filter stops the off-topic, the router separates the cases.
Lesson: filter = sort, router = direct.
Section vocabulary
- Filter
- Conditional gate: the scenario only continues if the condition is true (otherwise it stops).
Simple example: Lina: continue only if the subject contains QUOTE.
What it is not: routing to several branches.
Reflex: place the filter just after the trigger.
- Router
- Module (Make) creating several branches; each branch has its condition and its own sequence of actions.
Simple example: Business branch with alert, individual branch with automatic reply.
What it is not: a simple yes/no that stops everything.
Reflex: give each branch its own actions.
- Path
- Zapier equivalent of the router: conditional A/B/C branches by rules.
Simple example: Lina's A/B path in her sorting Zap.
What it is not: a single filter at the head of the scenario.
Reflex: name each path by its business case.
- Conditional logic
- “If… then… else…” rules that steer the scenario's behaviour by data.
Simple example: If business then alert, else reply automatically.
What it is not: processing everything, all the time, with no condition.
Reflex: write the rule in plain English before configuring it.
- Decision tree
- Structure of a scenario with branches and conditions, reproducing the business rules.
Simple example: Lina's sorting scenario: filter then two branches.
What it is not: a linear pipe with no sorting.
Reflex: check that each branch leads to a distinct action.
In practice — Adding filters and branches
- On your scenario, add a filter just after the trigger (e.g. “continue only if subject contains QUOTE”).
- Test: check that non-matching events are stopped (saved operations).
- Add a router/path with two branches by a condition (e.g. business vs individual).
- Give each branch its own actions (alert + handover on one side, automatic reply on the other).
Ready-to-say script — explaining your sorting live (30 s)
“My scenario filters first: only responses with QUOTE continue, the rest stops and uses no operation. Then the router separates: business to sales with an alert, individuals to the automatic reply. Each case has its actions, like our business rules.”
To say in a demo; show one case stopped by the filter and one case per branch.
Copy-paste template — filter + router sheet
FILTER (condition + position just after trigger): _______________
BRANCH A (condition + own actions): _______________
BRANCH B (condition + own actions): _______________
TEST (1 stopped case + 1 case per branch): _______________SMB / freelancer
One well-placed filter is often enough: process only the messages that really matter.
SME in Oran
Lina documents her two branches (business / individual) so the team knows where each request goes.
Digital team
Reproduce the written business rules: each scenario branch matches an existing rule.
Beginner
This week: one single filter after the trigger, tested with one passing case and one blocked case.
✓ Best practices
- Place filters as early as possible (savings + clarity).
- Use a router for distinct cases (A/B/C).
- Reproduce your explicit business rules in the scenario.
✗ Common pitfalls
- Confusing filter (yes/no) and router (routing).
- Placing a filter too late (wasted operations).
- Doing “everything, all the time” with no condition.
Key takeaways
- The filter only lets through what meets a condition (place it early to save operations).
- The router (Make) / paths (Zapier) create branches by conditions.
- Reproduce the “if… then… else…” logic of your processes.
- Filters + branches turn a linear pipe into a reliable decision tree.
48h challenge — apply tomorrow
Add 1 filter after your trigger and check that one off-topic case is stopped.
- I can tell filter (yes/no) from router (routing).
- I know how to place a filter early to save.
- My scenario has 2 branches with their own actions.
Frequently asked questions
What is the difference between a filter and a router?
A filter is a yes/no: either the condition is met and the scenario continues, or it is not and it stops there. A router is a junction: it creates several branches and sends execution to the matching one (case A, case B, case C…), each with its own actions. In short: the filter decides “do we continue or not”, the router decides “which way do we continue”. They are often combined: a router creates the branches, and each branch can have its own filter to refine further. The filter sorts, the router directs.
Why place filters as early as possible?
For two reasons. First savings: each executed action consumes a billed operation; a filter at the head stops irrelevant events cold before they trigger useless actions. Then clarity and reliability: you avoid running steps on data that should not be there (and so stray results or errors). Design rule: “filter early, act afterwards”. A scenario that processes 1000 events to keep only 50 useful ones wastes operations 950 times if the filter is badly placed.
Why place a filter as early as possible in a scenario?