Conditional Branching in Workflows: If This, Then That
Send work down different paths based on what earlier steps found.
Conditions depend on earlier results
A condition checks a value and chooses a path. The value must exist by the time the condition runs, so place conditions after the step that produces it. A contract review produces the number of issues found; a website scan produces a score; a new client record carries an amount. A common mistake is a condition at the start of a workflow that checks something nothing has measured yet.
Design both paths on purpose
Every condition has a Yes path and a No path, and both deserve thought. For a contract: if issues are found, give a person a task to review the flagged clauses; if not, send it for signature with reminders. For an amount: above the limit, ask for approval; below, proceed automatically. Make sure both paths reach a clear end, and that steps on the path not taken are shown as not run, so people reading the history are not confused.
- Place the condition after the step that measures the value
- Give the Yes path and the No path a clear end
- Show steps on the untaken path as not run
- Keep conditions simple: one value, one comparison
Keep conditions readable
Write conditions in words a client can read: issues found more than zero, amount more than five lakh, client email is known. Avoid stacking many conditions in one box; chain simple ones instead. Readable conditions make it easy for the client to trust and adjust the workflow without calling you.
Worked example: contracts with and without issues
A legal operations workflow starts when a contract is added. The review step reports how many clauses differ from the playbook. A condition checks issues found more than zero. On Yes, a lawyer gets a task to look at the flagged clauses before anything else happens. On No, the contract goes for signature with reminders every three days.
In the run history, the lawyer task shows as not run for clean contracts, so nobody wonders why it was skipped.
Common branching mistakes
Conditions are simple to add and easy to get wrong. A quick test run with sample data that hits each path catches most errors.
- Checking a value before any step produced it
- A path that never reaches an end
- Several comparisons in one condition
- Not testing both paths
- Put conditions after the step that produces the value.
- Design both paths to a clear end.
- Show untaken steps as not run in the history.
- Keep each condition to one readable comparison.
Add one condition to your mapped process. Name the step that produces its value, write the condition in plain words and sketch both paths to their ends.
Check your understanding
1. Where should a condition be placed?
2. What should happen to steps on the path not taken?
3. How should conditions be written?
Turn what you learn into monthly income
Resell AI agents and apps under your own brand. Up to 30% off credits, up to 30% recurring share, and apps built by XDQ Labs for your clients. Free to join.
From USD 49 or INR 2,999 a month. A person approves every step.
Templates from our playbooks
Copy ready templates with when to use each one and why it works.