Route a form with Make, including the awkward cases

Example result.

Case 1  returns,   review=false  → Returns queue only
Case 2  wholesale, review=false  → Sales queue only
Case 3  returns,   review=true   → Special review only (not Returns)
Case 4  other,     review=false  → General triage (fallback)
Case 5  returns,   review=blank  → General triage (fallback)

A scenario is the workflow, a module is a step and a bundle is one item moving through it. A router sends the bundle down every route whose filter matches.

1. Agree the routing rules before building

Start from a form field with a small, agreed set of values. A dropdown is easier to route reliably than an AI guess about a free-text message. If who handles what is still being argued about, building the router won’t settle it; it will just hide the argument in a diagram.

Input value | Destination | Owner
returns | Returns review queue | [owner]
wholesale | Sales review queue | [owner]
anything else, including blank | General triage | [owner]

Keep legally time-bound requests (such as data-access requests) and safety issues on their own intake, not a keyword route. Check who can read each queue before personal information goes into it.

To have AI check the table, paste it into a chat:

Review this form-routing table. We need exactly one destination for every submission. Find overlapping conditions, unmatched inputs and missing owners. Give a normal, overlapping, unknown-value and blank-value test case with its expected destination. Do not invent routing policy; flag unresolved decisions for us.

[table and the form's exact field values]

Why this works: test cases with expected destinations are what you’ll check the build against in step 5.

What you should see: a table with an owner per row, and four or five test cases.

2. Capture a test submission and add the router

Create a scenario with your form app’s trigger and run it with a fictional submission, so you can see the real field names and values. Then add a router: Add another module › Flow controls › Router, or right-click the link between two modules and choose Add a router. Add one route per destination.

Point each destination module at a test queue, and include the submission ID, received time and the original field value in every record.

Why this works: filters must use the values the trigger actually sends, not the labels on the form.

What you should see: a trigger, a router and one route per row of your table.

3. Make the filters exclusive

Click the link on each route to set its filter. Make runs routes one after another, and a bundle goes down every route whose filter matches; it doesn’t stop at the first. So putting “special review” first doesn’t stop the Returns route running too. Each lower-priority route has to exclude the higher-priority case itself:

Special review: needs_special_review Equal to true (Boolean)
Returns:        needs_special_review Equal to false (Boolean) AND type Equal to returns
Wholesale:      needs_special_review Equal to false (Boolean) AND type Equal to wholesale

Use Make’s Boolean Equal to for the flag, not a text comparison. A blank flag then matches none of these routes and falls through to the fallback, which is what you want: a missing decision goes to a person. If you’d rather catch blanks explicitly, Make’s Not exists operator matches an empty item.

Why this works: “explicitly false” is a different condition from “not true”. Only the first keeps a blank flag out of the Returns queue.

What you should see: every ordinary route requiring an explicit true or false.

4. Add an unrestricted fallback

Click the general-triage route, select Yes for fallback in its filter window and save. It receives any bundle that matches no other route. Don’t add a condition to it.

Why this works: a fallback catches unknown values. It doesn’t rescue a matched route whose destination later fails; that’s step 5.

What you should see: the fallback route marked with its own arrow icon.

5. Set up error handling before you switch it on

This is the step that saves you. Make disables an instantly triggered (webhook) scenario immediately if an error happens. A single unhandled error can switch your routing off entirely, and new forms then go nowhere.

• In scenario settings, turn on Store incomplete executions, so failed bundles are kept for review.
• Right-click each destination module, choose Add error handler and pick one:
  • Retry saves the failing bundle as an incomplete execution and lets the rest run. Usually right for enquiries.
  • Skip drops the bundle and still reports success. Wrong when a lost enquiry matters.
  • Resume substitutes an output you define and carries on.

Without a handler, Make rolls back by default. Then name a person who checks the incomplete executions daily. Turn the setting on and never open the tab, and you’ve converted loud failures into a filing cabinet.

Why this works: routing errors and delivery errors fail differently, and only handlers deal with the second.

What you should see: a handler on every destination module, incomplete executions on, and a named checker.

Check the result

• Run every test case. For each submission ID, exactly one destination record exists.
• A blank or unknown value lands in General triage.
• A forced failure on one destination appears in incomplete executions, and the scenario stays on.
• The count of form submissions matches delivered records plus unresolved failures.

The usual failure: one submission reaches two queues because two filters both match, usually a priority case that also meets an ordinary rule. Reordering routes won’t fix it. Spot it by searching every queue for the same submission ID.

These Make router filters sent [case] to more than one route: [filters]. Rewrite the filters so each of these test cases matches exactly one ordinary route or the fallback: [cases]. Use explicit conditions rather than route order. List the expected destination for each case.

[case] is the submission that duplicated; [filters] are your current filters; [cases] is your test list.

Fictional example. The first build used simple filters: Special review if needs_special_review is true; Returns if type is returns. Test results:

Case 3: "The lamp arrived with a cracked base. I have emailed twice." type=returns, review=true
  → Special review record 4471 AND Returns record 9013
Case 5: "Can I return an unopened box?" type=returns, review=(blank)
  → Returns record 9014

• The failure. Case 3 matched both routes, so two teams owned it. Case 5’s missing review decision was treated as “no review needed”.
• The repair. The repair prompt added needs_special_review Equal to false to the Returns and Wholesale routes. On re-test, case 3 created only a Special review record, and case 5 fell through to General triage. All five cases now match the example result.
• The delivery check. With the Sales queue made temporarily unavailable, case 2 failed. The Retry handler stored it as an incomplete execution, and the scenario stayed active. Without the handler, the webhook scenario would have switched itself off.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Compare these old and proposed routing rules. List every test case whose expected destination changes, and any new overlap or gap. Keep the exactly-one-destination requirement. Do not approve the change.

[both rule sets and the test cases]

Sources

• Make Help Center: Router
• Make Help Center: Filtering
• Make Help Center: Overview of error handling
• Make Help Center: Error handlers