Zapier Paths: route records without overlapping outcomes

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Use branches when the business needs different actions

Zapier distinguishes Filter, which stops nonmatching runs, from Paths, which routes data to different actions. Paths supports custom rules and a fallback for unmatched data. More than one branch can qualify unless rules make the outcomes exclusive. Current documentation describes sequential branch execution and notes that loop iterations remain parallel. Check the execution behavior in your own published workflow when timing matters.

Our design advice is to specify the full intended set of actions for each input. Do not infer that a familiar left-to-right diagram behaves like a programming language's exclusive if/else statement. A routing contract should say whether one or several outcomes are correct.

A fictional fulfilment decision

Assume a business sells downloadable files, physical items and mixed orders. Its proposed policy has three exclusive outcomes: digital-only orders receive file delivery, physical-only orders enter dispatch preparation, and mixed orders go to a combined fulfilment procedure. Unknown product classifications go to review.

The important sample is the mixed order. Rules such as contains digital and contains physical can both match it. If your contract requires only the combined procedure, add conditions that distinguish mixed from single-type orders rather than relying on branch position to suppress another match.

Make a routing worksheet

Configure for meaning before timing

1. Prepare a normalized classification and preserve the original source value.
2. Add Paths and name each branch by its business outcome.
3. Use custom rules derived from the worksheet and an intentional unmatched-data policy.
4. Test every sample against every branch, recording all branches that qualify.
5. Use disposable output records to confirm actual actions match the expected set.
6. Inspect timing separately, especially when a branch contains a delay or external dependency.

Our recommendation is to keep urgent operational actions out of a position where unrelated slow work can hold them up. If the workflow requires independent timing, redesign the boundaries and validate that design rather than assuming branches provide parallel execution.

Recover partial fulfilment carefully

Suppose one external action completes and another fails. A routing decision alone does not tell the operator which customer obligation remains. Keep the source order ID on each output and inspect destination state before replaying an entire order. Design a business key for operations that would be costly to duplicate.

If the same housekeeping action is needed by several outcomes, document where it lives and how it is maintained. Avoid quietly changing one copy while leaving another with an older mapping. Check the platform's current supported structure when deciding how to reuse that action.

Acceptance criteria

Accept the design when normal, mixed, unknown and incomplete inputs reach exactly the intended actions, when timing matches the business need, and when partial completion has an owner and a recovery procedure. This article supplies an editorial routing exercise; it does not claim a tested fulfilment integration or a delivery guarantee.