Understanding the flow of automation when a filter is set up on a router path
Here's how our completed automation looked at the end of the previous lesson:
When we run the automation, the “Search Rows” module retrieves all the rows from our “Quote Generation” spreadsheet and converts them into bundles.
Our spreadsheet contained five rows, so the “Search Rows” module created five corresponding bundles.
Usually, in automation tools like Make.com, N8N, and Zapier, when a module produces multiple bundles, each subsequent module in the workflow processes these bundles individually, one after another.
But what makes our current setup interesting is that the next step in our automation pipeline is not a standard module but a router module.
The router behaves similarly to standard modules when receiving data — it accepts all five bundles sequentially from the first module.
But unlike other modules, the router doesn’t process bundles or modify data.
Instead, it just acts as a traffic controller, splitting the automation into multiple paths and directing each bundle accordingly.
Here’s how it works:
- The router receives all five bundles sequentially.
- It evaluates each bundle against filters that we set up on each path.
- If a bundle matches a filter, it continues along that path. Otherwise, it's blocked from that path.
Based on these filtering criteria, some bundles will successfully pass through certain paths while being blocked from others.
For example, in our case, we have two different kinds of leads:
- Design & Development Leads → Sent through the first path → Receive a generic email template.
- Troubleshooting Leads → Sent through the second path → Receive a troubleshooting email template.
This way, our automation dynamically customizes outreach based on the nature of each lead.
Let me elaborate…
Step-by-Step flow of the automation Bundle Processing when a filter is set up on a router path
Run 1
In the first run (Run 1), the first bundle from the “Search Rows” module will reach the router.
After receiving the first bundle, the router sends it through all its paths one-by-one.
First, the router sends the first bundle through path 1.
And on path 1, the bundle goes through our filter before reaching the “Send an Email” step.
If you look at the first bundle's data, there's a key called “Service name? (D)”:
And inside the filter of path 1, we are checking whether “Service name? (D)” is equal to “building a landing page” or “converting your figma design to WordPress”.
Is “troubleshooting emails” equals to “building a landing page”?
Incorrect. Both are different text values.
If it was correct, the bundle could have passed through the filter and reached the “Send an email” step directly.
The second condition will not be checked by Make.com.
But since “troubleshooting emails” is not equal to “building a landing page”, Make.com will now check for the second condition.
Is “troubleshooting emails” equals to “converting your figma design to WordPress”?
Incorrect again. Both are different text values.
This means, both the conditions are not met.
So, the first bundle doesn't pass through the filter of path 1 and doesn't reach the “Send an Email” step.
We can verify this by opening up the Filter Inspector panel of path 1:
As you can see, the block sign indicates that both the checks are false.
Just to be on the same page because we have implemented the “Or” rule for both condition checks, the bundle could have passed through the filter if at least one condition was met if not both.
Anyway, irrespective of the fact that whether the first bundle was passed through the filter of path 1 or not, the router now sends the first bundle through path 2.
And on path 2, once again, the bundle goes through another filter before reaching the “Send an Email” step.
And inside the filter of path 2, we are checking whether “Service name? (D)” is equal to “troubleshooting emails” or “troubleshooting checkout”.
Is “troubleshooting emails” equals to “troubleshooting emails”?
Correct!
Since the condition is met, the first bundle passes through the filter, and the “Send an Email” step runs for it.
Finally, an email with the troubleshooting template will be sent to the lead.
And since the first condition inside the filter was met, Make.com doesn't even bother running a check for the second condition.
We can verify this by opening up the “Filter inspector” panel.
This is because we are using the “Or” rule between the condition checks.
Please remember that when an “Or” rule is implemented between the multiple condition checks, the bundle will pass through the filter even if one of the conditions is met.
Run 2
During the second run (Run 2), the second bundle from the “Search Rows” module will reach the router.
After receiving the second bundle, the router sends it through all its paths one-by-one.
First, the router sends the second bundle through path 1.
And on path 1, the bundle goes through our filter before reaching the “Send an Email” step.
If you look at the second bundle's data, there's a key called “Service name? (D)”:
And inside the filter of path 1, we are checking whether “Service name? (D)” is equal to “building a landing page” or “converting your figma design to WordPress”.
Is “building a landing page” equals to “building a landing page”?
Correct. Both are the same text values.
Since the condition is met, the second bundle passes through the filter of path 1, and the “Send an Email” step runs for it.
Finally, an email with a generic template will be sent to the lead.
And since the first condition inside the filter was met, Make.com doesn't even bother running a check for the second condition of path 1.
We can verify this by opening up the “Filter inspector” panel.
This is because we are using the “Or” rule between the condition checks.
Anyway, irrespective of the fact that whether the second bundle was passed through the filter of path 1 or not, the router now sends it through path 2.
And on path 2, once again, the bundle goes through another filter before reaching the “Send an Email” step.
And inside the filter of path 2, we are checking whether “Service name? (D)” is equal to “troubleshooting emails” or “troubleshooting checkout”.
Is “building a landing page” equals to “troubleshooting emails”?
Incorrect. Both are different text values.
If it was correct, the bundle could have passed through the filter and reached the “Send an email” step directly.
The second condition will not be checked by Make.com.
But since “building a landing page” equals to “troubleshooting emails”?, Make.com will now check for the second condition.
Is “building a landing page” equals to “troubleshooting checkout”?
Incorrect again. Both are different text values.
This means, both the conditions are not met.
So, the second bundle doesn't pass through the filter of path 1 and doesn't reach the “Send an Email” step.
You get the idea, right?
Next, Make.com automatically moves to the third bundle and repeats the process.
This cycle repeats until all bundles have been processed, ensuring that each lead gets the correct quote email.
That's all.
That's how data mapping and automation work inside Make.com when a filter is set up on a router path.
And, based on what you have learned so far, I have a small challenge for you in the next lesson.
