Conditions and Branching
A condition node evaluates a test and sends the run down one of two paths.
Where to find it
Architect Panel → Automation:
- Workflow Builder — the canvas, nodes and edges
- Worklist — what is waiting on a person
Two ports, always
True and false. Both should go somewhere — a false branch with no edge is a run that stops silently, which looks identical to a run that finished.
If nothing should happen on one branch, connect it to something that says so rather than leaving it dangling.
One question per condition
A condition testing three things at once is a condition nobody can debug, because a run down the false branch could have failed any of the three.
Chained conditions are longer to draw and enormously easier to read in the run history, where each step is recorded separately.
Put the common path first
Most runs should follow a short, obvious route. Exceptions branch off it. A canvas where the ordinary case wanders through six conditions is one nobody can reason about.
Label the edges
What the branch means, not which port it left. "Over £5,000" and "Standard" are readable; "true" and "false" require reading the condition every time.
Beware the empty branch
The commonest bug in a workflow. A condition where somebody drew the true path and forgot the false one, so a proportion of records silently stop part way through a process.
Nothing errors. The run simply ends, and it looks like every other completed run.
Test both branches
Every condition, both ways, with real records. Testing only the path you expected is how a false branch reaches production untested — and it is the branch that handles the awkward cases.
Watch for conditions on values that change
A condition evaluated after a wait sees the record as it is now, not as it was when the run started. That is usually what you want and occasionally a surprise — a case closed during a three-day wait will take an unexpected branch.
Keep the canvas readable
Node positions are stored, so layout is yours to control. Left to right, branches down, no crossing edges where avoidable. A workflow is documentation as well as automation, and a tangle is neither.
Worked example
An approval workflow branches on value, then on whether the requester is in a particular team, as two separate conditions rather than one combined test. Both branches of each go somewhere. The run history shows which specific test sent a case down the escalation path.
Recommendations
- Connect both ports of every condition.
- One question per condition.
- Label edges by meaning.
- Test both branches with real records.