Short answer
Do not automatically interpret a router as mutually exclusive conditions. One record can match multiple filters. Decide whether several actions or just one should run and write conditions matching that policy. The fallback route handles data not matching the other routes; review any filter on the fallback itself.
Key verification: Test cases produce exactly the intended routes, including the record matching two filters.
Sources and limitationsA scenario sends Spanish contacts to one queue and urgent contacts to another. A contact may satisfy both conditions. Before investigating duplicate webhooks, check whether the design requests two actions for this single record. Reordering the branches visually does not make the conditions mutually exclusive.
Original match matrix
| Country ES | Urgent | Routes with independent conditions |
|---|---|---|
| Yes | Yes | Spain and urgent |
| Yes | No | Spain |
| No | Yes | Urgent |
| No | No | Fallback if configured |
The first row is correct when adding a geographic tag and notifying an owner. It is wrong if both branches send the same quote. Write the intended business result before changing filters: one assignment per contact and all applicable notifications require different policies.
Sequential does not mean exclusive
The Make router documentation states that routes are processed sequentially, not in parallel, and that a fallback route processes data that doesn't fit the condition of all other routes. Sequential is not the same as exclusive: Make checks each route's filter separately and runs every one that matches, one after another, unless you have written filters that exclude each other yourself.
For one priority assignment, a possible policy is urgent first and Spain only when not urgent; translate that policy into filters and recheck the complete matrix.
Exercise without external effects
Create fictional records with different identifiers and replace sending actions with inspection outputs. Record expected and observed routes for each case, including no match. Then add missing-country behaviour according to the data contract. Investigate route failures separately: fallback is not a universal error handler. Make is relevant when executing this routing; the table is enough to decide conditions. CallsIQ has not run the scenario.
Turn a priority into mutually exclusive conditions
For a single assignment, first define "urgent": this exercise uses a validated boolean, not any non-empty text. Country is a normalised two-letter code. The proposed policy prioritises urgent records from any country, then non-urgent Spanish records, then a review queue.
| Fictional record | Country | Urgent | Expected route | Reason |
|---|---|---|---|---|
| R-01 | ES | true | Urgent | Spain route requires false |
| R-02 | ES | false | Spain | Matches both conditions for that route |
| R-03 | FR | true | Urgent | Country does not restrict priority |
| R-04 | FR | false | Review | No ordinary route matches |
| R-05 | Missing | Unknown | Data review | Unknown is not converted to false |
Express ordinary filters as urgent = true and country = ES AND urgent = false. Set the review route as fallback and check its own filters if any exist. R-05 needs a validation or review decision; if the scenario rejects it before the router, fallback cannot be expected to recover it.
Edge case: months later a fourth route gets added for "VIP" contacts, with the filter vip = true, without touching the other three. R-01 (ES, urgent) now also matches the VIP route if that contact is flagged VIP, and activates two branches in the same execution again: the urgent one and the new VIP one. The fault is not in the original filters, which remain mutually exclusive among themselves, but in the fourth route being designed without repeating the full matrix exercise. Every new filter requires rechecking combinations against every existing filter, not just the one that prompted the change.
Two different failures that resemble a duplicate
If R-01 activates two branches within one execution, conditions overlap. If it appears once in each of two executions, the source may have repeated or resent an event. Retain event identifier, execution and observed route to distinguish them. Mutually exclusive branches do not prevent the same event being received twice.
| Observed symptom | Likely cause | How to confirm it |
|---|---|---|
| Two actions in the same execution, same event ID | Overlapping filters inside the router | Check whether two routes share non-exclusive conditions for that record |
| The same action twice, in two different executions | Repetition or resend of the source event, not the router | Compare the execution ID: if they are two separate executions, the router is not the cause |
| A business action duplicated even though the router is exclusive | Missing stable key or concurrency control at the destination | Check whether the destination looks up and writes without locking between simultaneous executions |
| A record never reaches any route or the fallback | The scenario discards or transforms it before the router | Review the modules before the router with the inspection output |
Where a commercial action must not repeat, define a stable key such as event plus action type and keep an outcome record. Checking and reserving that key must withstand simultaneous executions; looking up and then writing without concurrency control can permit two sends. Implementation depends on storage and the destination API, not the router's visual order.
Common mistakes and how to spot them
| Mistake | Symptom | Check |
|---|---|---|
| Treating the router as an if/else | Two branches run for the same record without that being intended | Check whether both routes' filters can match at once with the same data |
| Trusting visual order to exclude branches | Changing the order of routes does not change what runs | Review each route's filter, not its position in the scenario |
| Treating fallback as an error handler | A destination API failure disappears without a trace | Keep each branch's error handling separate from the logic of which branch runs |
| Accepting any text as a boolean | The string "false" evaluates as true | Validate the field as a real boolean before the router, not as non-empty text |
| Turning a missing country into "not Spain" | A record with no country falls into a route meant for another case | Send records with the missing field to review, not to an ordinary route |
| Not rerunning the matrix when a route is added | An old combination, once unique, now triggers two routes | Rerun the exercise with one row per existing filter, including the new one |
Acceptance criteria before enabling sends
Run the matrix in an authorised environment with inspection actions. Each valid record must produce exactly one assignment under this policy. Repeat an event and check duplicate handling separately. Then induce a destination failure during the rehearsal: it must remain visible for recovery, without treating fallback as an error-handler substitute. Record observed outcomes and unresolved cases before connecting real quotes or notifications.
From the author's experience
Across eleven years developing and implementing contact centre software (at Vocalcom, on the .NET/C#/APIs side), I've worked with a fair amount of event-routing logic, and the overlap I've run into most often is category and urgency filters that can both be true at once: the first thing to settle is whether that should trigger independent actions or just one, because the filter matrix alone doesn't answer that business question.
I wouldn't venture a frequency for how often people forget to recheck combinations when adding a new route without having reviewed the actual scenarios first; what I do always insist on is rerunning the complete combination matrix every time a route gets added, not just checking the new route against the old one that prompted it.
To tell apart an overlapping-filter issue from a resend of the source event, the piece of data that's served me best in practice is comparing the event ID, the execution ID and the routes actually taken; that cleanly separates one execution with several branches from several deliveries of the same event. And of the common failures, the one that causes the most billing or duplicate-notification incidents is an external action repeating across overlapping branches, so I add a guard per business operation whenever that action should only fire once. Before wiring up real sends, I cover every filter combination, its edge cases and the no-match scenarios: what matters is behaviour coverage, not an arbitrary number of test records.
Sources and limitations
Documentary review: . Content type: Documentation-based guide with original exercise.
Linked sources describe the terms and capabilities each provider publishes. Examples that use fictional data are labelled in the text.
Scope: Documentation reviewed on 16 October 2026. Examples are fictional and tests are proposed; CallsIQ has not performed product tests.
- Make router documentationhelp.make.com
Check current terms
Consider these options if they solve the problem described. Confirm features, limits and availability in your country.
MakeAffiliate linkThe labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.
Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.