Make Router filters: design routes without duplicate actions

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Write the routing contract before drawing branches

A Make Router splits a scenario into routes with filter conditions. Routes are processed sequentially rather than in parallel, and you can choose their order. A fallback route handles data that does not satisfy the other routes' conditions. Use these documented mechanisms to implement an explicit business rule rather than assuming a visual branch means a mutually exclusive choice.

Our recommendation is to decide whether an event should reach one destination or several. “Assign one owner” and “notify every interested team” require different acceptance criteria. The diagram can look similar while the correct outcomes differ.

A fictional enquiry assignment policy

Assume a service company wants website enquiries assigned by service and budget. Its proposed policy is: website work with budget at least 5,000 goes to Sales; website work below 5,000 goes to Starter Services; everything else goes to Triage. These are illustrative company rules, not recommended sales thresholds or software settings.

Decide the missing-budget rule before building filters. Do not silently treat a blank as zero unless the business owner has chosen that meaning. Include the same service constraint on both budget routes so a high-budget non-website enquiry does not get the wrong owner.

Validate filters without sending messages

1. Normalize service labels and budget types before the router, preserving the original values for diagnosis.
2. Create filters from the written policy and name routes by outcome.
3. Mark the intended unmatched route as fallback and inspect its settings.
4. Replace external notifications with a disposable log during validation.
5. Run every row in the truth table and record all routes reached, not only the first visible one.
6. Enable external actions only when observed destinations match expected destinations.

Handle overlap deliberately

For an exclusive owner assignment, our acceptance rule is exactly one owner per valid enquiry. If a record satisfies two route conditions, repair the predicates instead of relying on branch position as your business rule. For a fan-out design, write the intended set of destinations and verify that set; multiple actions may be correct in that case.

Consider side effects separately from filtering. A route that fails after creating an activity can leave a partial result. Keep the enquiry ID on every output so the owner can reconcile it without creating another activity simply because a notification failed.

When to revise the design

Add another truth-table row whenever a new service, currency, missing-field case or threshold enters the policy. Recheck the boundary rows after editing a filter. Keep the table beside the scenario's operating notes so a colleague can explain the route without guessing from the canvas. This is an editorial implementation checklist, not a tested Make configuration or a guarantee about your data types.