Zapier Paths: How to Build Branching Logic Into a Zap

Zapier Paths lets a single Zap do different things depending on the data it receives. You add a Paths step after your trigger, create two or more branches, give each branch rules (for example “Lead type exactly matches Enterprise”), and add the actions that should run in that branch. When the Zap runs, Zapier checks each branch’s rules and runs the branches that match.

Without Paths, you either build several near-identical Zaps with different filters, or you accept one workflow that treats every record the same. Paths keeps related logic in one place. This guide covers how to set it up, how to write rules that behave predictably, and when a different tool is a better fit.

When Zapier Paths is the right tool

Paths is built for “if this, do that; otherwise, do something else” decisions that change which actions run. Typical examples:

• Lead routing: enterprise leads go to the sales team’s CRM pipeline and a direct alert; small leads go into a nurture sequence.
• Order handling: digital products trigger a download email; physical products create a fulfilment task.
• Form handling: a support request opens a ticket; a partnership inquiry goes to a different inbox.
• Payment events: successful payments update the customer record; failed payments notify the account manager.

Before you add Paths, ask whether you need different actions or just different values. If every record gets the same actions and only one field changes, such as which person owns the lead, a Formatter lookup table is simpler than branching. If records either continue or stop, a Filter step is enough.

How to add Paths to a Zap

1. Build and test your trigger first. Paths needs real sample data to test its rules.
2. Add any steps that every record needs before the branch, such as cleaning data or finding an existing contact. Do this now, because you can’t add shared steps after Paths.
3. Add a new step and choose Paths. Zapier creates a path group with two branches.
4. Rename each branch to describe what it handles, such as “Enterprise lead” and “Small business lead”. Default names like “Path A” are hard to read in Zap history later.
5. Open each branch and set its rules.
6. Add the actions for that branch inside it.
7. Test each branch’s steps with sample data that should match it.
8. Add more branches if you need them, and set a fallback (covered below).
9. Publish, then watch Zap history to confirm records go where you expect.

Writing path rules that behave predictably

Each branch can use one of three rule settings.

Custom rules

Custom rules are the standard option. Each rule has a field, a condition and a value: for example “Company size”, “(Number) Greater than”, “50”. You can combine rules with “and” (every rule must match) or “or” (at least one must match).

Pick the condition type carefully. Text conditions such as “contains” and “exactly matches” behave differently from number conditions, and comparing numbers with a text condition gives odd results. If a field might contain extra spaces or different capitalization, clean it with a Formatter step before Paths so the rule matches reliably.

Always run

An “always run” branch runs every time. That sounds pointless, but it is useful when you want one branch to handle shared work in parallel with the conditional branches, such as logging every record in a spreadsheet.

Fallback

A fallback branch runs only if no other branch in the group runs. You can only have one fallback per group. Always add one. Without it, a record that matches none of your rules simply ends the Zap with nothing done, and nobody notices.

Use the fallback for something visible, such as a message to a team channel saying “Unrouted lead: please review”, with the key details attached.

Understand how Zapier runs branches

A few behaviours catch people out:

• More than one branch can run. Zapier checks every branch separately. If a record matches two branches, both run. If you want exactly one outcome, make the rules mutually exclusive, for example “Company size less than 50” and “Company size greater than or equal to 50”.
• Branches run one at a time, left to right. A slow step in one branch, such as a Delay, holds up the branches after it. Order affects timing, not which rules match.
• An error in one branch doesn’t stop the others. Later branches still run, so check Zap history for partial failures.
• Paths must be the last step. You can’t add a step after the branches that applies to all of them. Repeat the step in each branch, or call a Sub-Zap that holds the shared steps.
• Nesting is possible but limited. You can put a Paths step inside a branch for a second level of decisions. Zapier caps the number of branches, nesting levels and total steps, so check the current limits in Zapier’s help center before you design something deep.

Design the branches on paper first

Branching Zaps get confusing fast. Before you build, write a simple decision table:

This table shows overlaps and gaps before they become bugs. It also becomes the documentation your team needs when someone asks “why did this lead go to marketing?”

A worked example: routing inbound form leads

Say your contact form asks for company size and the type of help needed.

1. Trigger: new form submission.
2. Formatter: trim and lowercase the “type of help” answer.
3. Find contact in CRM: check whether this person already exists.
4. Paths, with the four branches below.
5. Branch “Existing customer”: rule “Contact ID exists”. Action: create a task for the account manager.
6. Branch “New, large company”: rules “Contact ID does not exist” and “Company size greater than or equal to 50”. Actions: create contact and deal, alert sales.
7. Branch “New, small company”: rules “Contact ID does not exist” and “Company size less than 50”. Actions: create contact, add to nurture sequence.
8. Fallback: notify operations with the raw submission.

Notice that the branch rules don’t overlap, the shared clean-up and lookup steps happen before Paths, and the fallback catches anything unexpected, such as a blank company size.

If the data is arriving from a system without a native integration, you can start a Zap like this with a Catch Hook; see our guide to Webhooks by Zapier for the setup.

Paths, Filters, lookup tables or separate Zaps?

• Filter: use when a record should either continue or stop.
• Lookup table: use when every record follows the same steps but one value changes.
• Paths: use when different records need different actions.
• Separate Zaps: use when the workflows share a trigger but are owned by different teams and change on different schedules.
• Code step: use when the decision depends on many fields at once and rules become unreadable; our post on Python in Zapier shows how to return a single “route” value that a simple Paths step can then use.

Common mistakes with Zapier Paths

• No fallback branch, so unmatched records vanish.
• Overlapping rules that run two branches and create duplicate records.
• Text conditions used on numbers.
• Branches named “Path A” and “Path B”, which make Zap history hard to read.
• Shared steps copied into every branch and then edited in only one.
• Testing only the branch you expect most records to take.

When branching logic needs a developer

Paths handles most routing decisions well. When the logic grows to several nested levels, many duplicated steps, or decisions that depend on data from other systems, the Zap becomes hard to change safely. That is when it helps to work with a Zapier developer who can restructure the logic with Sub-Zaps, code steps or a cleaner design. You can send the workflow details to support@growthscribe.com.

FAQ

Can more than one path run at the same time?

Yes. Zapier checks each branch’s rules separately, so if the data matches the rules of two branches, both run. If you want only one branch to run, write rules that cannot overlap, and use a fallback branch for anything that matches none of them.

Can I add steps after a Paths step that apply to every branch?

No. A Paths step has to be the last step in a Zap, so you can’t add shared steps after the branches. Either repeat the shared steps inside each branch or move them into a Sub-Zap that each branch calls.

What is a fallback path in Zapier?

A fallback path is a branch that only runs when no other branch in the same path group runs. It catches records that match none of your rules, so they don’t silently disappear.

Is Zapier Paths available on the free plan?

Paths is a paid feature. Check Zapier’s current plans page for which plans include it and for any limits on branches or nesting.