Use a Zapier Filter to either continue one workflow or stop. Use Paths for different actions. Several paths can match the same submission; placing a branch first does not make it the only winner.
This guide covers designing the decision inside a Zap. If you are still choosing an automation platform, start with our Make versus Zapier comparison.
Table of Contents
Zapier Filters vs Paths: start with the outcome
Decide what happens when an enquiry fails your main condition. Use a Filter to stop it, or plan a branch for another team to investigate it. Zapier’s conditional-logic overview explains this distinction.
Both tools currently require a paid plan: Professional, Team or Enterprise. “No tasks consumed by the decision step” does not mean the feature is available on Free. Check your account before designing a workflow around it.
For each proposed branch, name its owner and useful output. “High priority” is too vague; “create an estimator review task assigned to the commercial team” gives you something concrete to verify.
Put a Filter before the work it controls
After configuring the trigger, add an action step and select Filter. Choose the earlier field to inspect, the condition and the comparison value where required. A filter can sit anywhere after the trigger, and a Zap can contain several. Follow Zapier’s filter setup instructions.
For example, a quotation workflow might accept only submissions whose enquiry type is Quote. Put that check before creating the sales task. Treat it as a decision about later steps, rather than a way to reverse work already performed.
Check the actual trigger output instead of guessing the field name from its label on the form. A field named “Service” might contain a readable answer, an internal identifier or several values.
Use the correct field type and AND/OR logic
Zapier’s rule reference separates text, number, date/time, Boolean and generic conditions. Use a number condition for a numeric quote estimate. Decide how to handle missing values before comparing them with a threshold.
AND requires every condition; OR needs at least one. Suppose an enquiry must be a Quote and have a UK service location. Joining those checks with OR also admits non-quote UK enquiries and quotes from elsewhere. Write the intended sentence first, then translate it into rules.
Prefer controlled answers for routing fields. If the form itself needs restructuring, our Jotform versus Typeform guide compares the wider collection workflow.
An illustrative quote-enquiry routing plan
Imagine a maintenance business accepting either Domestic or Commercial work. Its proposed internal process has the following outcomes. This is a design example, not a tested integration or a recommendation to send automatic quotations.
| Submission | Route | Intended result |
|---|---|---|
| Enquiry type is not Quote | Filter stops quotation workflow | No sales task from this Zap |
| Quote; customer type Domestic | Domestic custom branch | Task for the residential estimator |
| Quote; customer type Commercial | Commercial custom branch | Task for the commercial estimator |
| Quote; customer type blank or unexpected | Fallback branch | Manual triage task |
Use one single-choice customer-type field for this example. The business still needs a separate process for non-quote submissions; deliberately stopping this Zap should not mean losing the original enquiry.
A matching path is not automatically exclusive
Add Paths as an action, then configure each branch’s rules and actions. At least one action is required per branch. Zapier’s Paths guide warns that conditions can overlap.
For example, a Domestic branch and a second branch accepting every estimate over £5,000 both match a £6,000 domestic enquiry. Decide whether two tasks are intentional. If only one team should own it, rewrite the conditions so the routes cannot overlap.
A Fallback branch covers cases where no other branch’s rules match. Only one fallback is allowed per group, and it cannot share that group with an Always run branch. Use fallback for unclassified data; it is not a substitute for designing how failed actions will be handled. See the rule-type explanation.
Check order and shared actions before expanding
Branches execute sequentially from left to right. A delay in an earlier branch can hold up a later matching branch. Also, a Paths step ends the shared workflow: there is no common action slot after all branches. Zapier suggests duplicating shared actions inside branches or using a Sub-Zap. These constraints are documented in the Paths setup guide.
Put a genuinely shared prerequisite before the split. Keep a result-specific action with the branch that owns it. Draw the intended order on paper if that makes the handover easier to explain.
Test outcomes and task usage
Before switching on the workflow, prepare a small acceptance set: one normal submission per route, a blank customer type, an unfamiliar answer, a non-quote enquiry and an overlapping case. Record the expected owner and number of tasks in the destination app for each.
Inspect the selected sample for every rule, then check a controlled run’s actual outputs. Zap history exposes step status, received and sent data, and task usage. A successful run is insufficient evidence if it created work for the wrong person.
Filter and Paths steps do not consume Zapier tasks, and steps that never run are not counted. Successful downstream actions generally do count, with product-specific rates. Check the task accounting rules and measure your actual workflow rather than counting the boxes in its diagram.
Keep the acceptance set with the workflow owner’s notes. Rerun it when changing the form, threshold or branch rules, and ensure somebody regularly checks the manual triage queue.
Sources reviewed 24 September 2026 against official Zapier documentation. The maintenance-business workflow is illustrative.
