How do I use if then branches in a workflow?
Short answer
If then branches split a workflow into different paths based on a condition, such as job type, deal value, or whether a customer replied. Add a condition step, define the true and false paths separately, and only branch on the handful of conditions that actually change what should happen next.
Before you start
- A working workflow that already runs from a single trigger.
- A specific condition that should change what happens next, written as a clear rule.
- The data field the condition depends on, such as a tag, a value, or a stage.
- A test contact for each side of the branch you plan to add.
Step by step
- 1
Write the condition as a plain sentence
State the rule exactly, such as if the job value is over a set amount, or if the contact replied within an hour, before adding anything to the workflow.
A branch built around a fuzzy condition is impossible to debug later.
- 2
Confirm the field the condition checks actually exists
Check that the tag, custom field, or stage the condition relies on is reliably set on every contact entering the workflow.
A branch checking a field that is often blank will send most contacts down the wrong path.
- 3
Add the condition step at the right point
Insert the if then step exactly where the paths should diverge, not earlier, so both paths share any setup steps that apply to everyone.
Branching too early duplicates work that both paths need anyway.
- 4
Build the true path completely before touching the false path
Fill in every action for the condition being met, run it in your head end to end, then move to the other branch.
Jumping between branches half-finished is how one side ends up missing a step.
- 5
Build the false path with equal care
Do not leave the else path as an afterthought; give it its own complete sequence of actions, even if shorter than the true path.
The path that gets ignored during building is usually the one that breaks in production.
- 6
Avoid stacking more than two or three branches deep
If a decision needs several nested conditions, consider splitting it into two workflows connected by a tag instead of one deeply branched workflow.
A workflow with branches inside branches becomes unreadable within a month.
- 7
Test both sides with real contacts
Run one test contact through the true path and a separate one through the false path, checking the messages and actions each actually receives.
Testing only the path you expect most people to take leaves the other one unverified.
- 8
Review branch performance after it runs live
After a week, check how many contacts went down each path and whether the split matches what you expected.
A branch sending far more or fewer contacts down one path than expected usually means the condition is wrong.
What good looks like
- Commercial and residential leads, or big and small deals, get treated differently without separate workflows to maintain.
- Fewer generic messages get sent to contacts they clearly do not fit.
- The team can see exactly why a contact took the path it did.
- Workflows stay understandable because branches only exist where they change the outcome.
Common mistakes
The ways this goes wrong in automation, and what to do instead.
Branching on a field that is often blank›
If the condition checks a tag or field that only gets set some of the time, most contacts fall through to the wrong side by default.
Do this instead: Confirm the field is reliably populated before building the branch around it.
Only testing the expected path›
Publishing after testing just the true path means the false path runs live completely unverified.
Do this instead: Send a test contact down each branch and check every message before publishing.
Nesting branches too deep›
Conditions inside conditions inside conditions become impossible for anyone but the original builder to follow.
Do this instead: Split deeply nested logic into separate workflows connected by a tag or stage.
Adding a branch nobody asked for›
Branching on a condition that does not actually change the messaging or actions adds complexity without any benefit.
Do this instead: Only add a branch when the two paths genuinely need different actions.
Frequently asked
6 questions about use if then branches in a workflowRelated guides
Pick the next thing to set up, or back up a step if something here assumed work you have not done yet.
Do this next
The natural follow-on tasks once this one is working.
People usually get here from
Guides that lead into this one, in case you skipped a step.
More in Automation
Nearby tasks that share the same setup and vocabulary.
Was this guide helpful?
Tell us what worked and what didn't. It shapes what we rewrite next.
You didn't get into business to be in the tech business.
Managed Tech clients hand this to us. We build it, test it, maintain it, and add to it as the business changes, so nobody on your team has to become the person who knows how the system works.