Understanding the flow of automation when a filter is set up

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 of our “Client Payment Tracker” 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 generates multiple bundles, the next module in the automation pipeline processes every bundle individually.

In our case, this means that the “Send an Email” module would execute five separate times—once for each bundle created by the “Search Rows” module.

But, we've implemented a filter between these modules, right?

This filter acts as a gatekeeper, evaluating each bundle against our criteria and deciding which ones should proceed to the next step.

So, some bundles make it through the filter, and others don't.

In other words, think of this filter like a bouncer at a club — it checks each bundle and decides “you can pass” or “sorry, not today.”

Let me elaborate…

Step-by-Step flow of the automation Bundle Processing when a filter is set up

Run 1 (Checking Bundle 1 against the filter set)

In the first run (Run 1), the first bundle from the “Search Rows” module 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 “Got paid? (G)”:

And inside our filter, we are checking whether “Got paid? (G)” is “No”.

When the automation runs, the dynamic placeholder “1. Got paid? (G)” gets replaced with the actual value from the first bundle.

In this case, it translates to “Yes”.

Is “Yes” equal to “No”?

Incorrect, right?

“Yes” and “No” are not the same words.

Since the condition isn't met, the first bundle doesn’t pass the filter, and the “Send an Email” step doesn’t run.

As a result, client Andy won't get a payment reminder email — which is exactly what we want since Andy already paid!

We can verify this by opening up the “Filter inspector” panel:

As you can see, Bundle 1 was stopped by the filter because “Yes” is not equal to “No”.

Make.com then moves to the next bundle and repeats the process.

Run 2 (Checking Bundle 2 against the filter set)

In the second run (Run 2), the second bundle goes through our filter before reaching the “Send an Email” step.

If you look at the second bundle's data, the value of the “Got paid? (G)” key is set to “Yes” again:

And inside our filter, we are checking if the second bundle's value for “Got paid? (G)” is equal to “No”.

Again, is the value “Yes” equals to “No”?

Incorrect, right?

“Yes” and “No” are not the same words.

So, just like the first bundle, the second bundle doesn't pass through the filter and the “Send an Email” step doesn't run for it.

As a result, client Jon won't get a payment reminder email.

Once again, we can verify this by opening up the “Filter inspector” panel:

As you can see, Bundle 2 was stopped by the filter just like Bundle 1.

Next, Make.com automatically moves to the third bundle and repeats the process.

Run 3 (Checking Bundle 3 against the filter set)

In the third run (Run 3), the third bundle goes through our filter before reaching the “Send an Email” step.

If you look at the third bundle's data, the value of the “Got paid? (G)” key is set to “No” because the client didn't pay:

And inside our filter, we are checking if the third bundle's value for “Got paid? (G)” is equal to “No”.

Is the value “No” equals to “No”?

This time it is correct, right?

Both “No” and “No” are the same words.

So, unlike the first two bundles, the third bundle does pass through the filter and the “Send an Email” step does run for it.

As a result, client Jennifer will get a payment reminder email.

We can verify this by opening up the “Filter inspector” panel yet again:

As you can see, Bundle 3 was not stopped by the filter, and it gets processed by the “Send an email” module.

In other words, the dynamic placeholders inside the email module get replaced with values from Bundle 3 and an email will be sent.

So, by the end of Run 3, when the payment reminder is sent to the client, it should look like this:

Next, Make.com automatically moves to the fourth bundle and repeats the process.

You get the idea, right?

This cycle repeats until all bundles are processed, ensuring that clients who haven't paid receive a payment reminder.

That's all.

That's how data mapping and automation work inside Make.com when a filter is set up.

Now that you understand filters and how to set up them, starting from the next lesson, we will start improvising the “Quote Generation” automation.

We’ll focus on:

1. Using a router to apply different templates based on the service type.
2. Implementing a complex “OR” rule-based filter to select the right template for each service name.

I will see you in the next lesson.