Loading

Conditions and Branching

Branching is how a workflow treats records differently: a Condition sends a run down Yes or No, and a Parallel step sends it down several paths at once that a Join later brings back together. This page covers all three steps and the mistakes that leave runs ending quietly.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — Condition, Parallel and Join are in the Flow group of the Steps palette

Setting up a Condition

  1. Add a Condition step and connect the step before it into it.
  2. Choose Go down 'yes' when: every condition is true, or any condition is true.
  3. Add rows under Conditions. Each row has a Field, a Comparison and a Value.
  4. Connect both the Yes and the No port to the next steps.
  5. Give the step a name that asks the question, such as "Over 5,000?".

What a row can compare

  • Field: a field of the record, or a value from an earlier step, such as found.status after a Look up saved as "found".
  • Comparison: equals, does not equal, is more than, is less than, is at least, is at most, contains, does not contain, starts with, ends with, is one of (a, b, c), is none of (a, b, c), is empty, is not empty.
  • Value: a fixed value or a placeholder such as {{credit_limit}} or {{today-30}}. "Is one of" takes a comma-separated list. "Is empty" and "is not empty" take no value.

"Equals" and "does not equal" compare as text. "Is more than", "is less than", "is at least" and "is at most" compare as numbers when both sides are numbers, as dates when both sides are dates, and as text otherwise.

On ERP datastores many columns hold the ID of a pick-list entry. If you type a word such as approved, the engine looks it up among that list's codes and compares the ID. A word that is not one of the codes never matches, and Validate warns, listing the codes it accepts.

A Condition with no rows is an error: Validate refuses to let it be published.

Parallel and Join

  1. Add a Parallel step and draw two or more lines from its Next port.
  2. Build each branch as usual.
  3. Where the branches should meet, add a Join and draw every branch into it.
  4. Set the Join's Carry on when: every incoming branch has arrived, the first branch arrives, or 2, 3 or 4 branches have arrived.

The branches run one after another within the same run, not at the same instant. A branch that waits (for an approval or a Wait) parks the run, and the others carry on when it resumes. A branch that reaches the Join after it has already carried on ends quietly. "Every incoming branch" counts the lines drawn into the Join.

A common pattern asks for an approval on one branch and runs a Wait plus a reminder on the other, so a slow approver is chased without stopping the request.

What goes wrong

  • A run ends after a Condition with nothing else recorded. The port it took has no line. Validate warns: "The 'false' path is not connected, so the run ends here…". Connect it, even if only to an End step.
  • Only one branch runs. Several lines leave a port of a step that is not Parallel; only the first is followed. Add a Parallel step.
  • A Join never carries on. It expects every branch, and one branch ended or went another way. Use "the first branch arrives" or a number, or route that branch into the Join too.
  • A runaway loop. Steps that lead back on themselves with no Wait in between are stopped by the engine; Validate warns about the loop.
  • The wrong branch after a long wait. A Condition reads the record as it is now. A case closed during a three-day wait takes the branch for a closed case, which is usually what you want.

Testing branches

Use Test… then Simulate. Under Sample data and decisions, add field values to push the record down each branch in turn (a larger amount, another status) without changing the record. The path the simulation took is drawn on the canvas. See Simulating a Workflow.

Worked example

An expenses workflow first asks "Over 500?" (amount is more than 500). No goes straight to Set status Approved. Yes goes to a second Condition, "Travel?" (category is one of Rail, Air, Hotel), whose Yes path asks the travel manager and whose No path asks the line manager. Both paths end at their own End step. Two simulations with amounts of 200 and 800 confirm both routes before the workflow is published.

Recommendations

  • One question per Condition, so the run history shows which test sent a record where.
  • Connect both ports of every Condition.
  • Use Parallel only for real side-by-side work, and always close it with a Join.
  • Compare pick-list columns with their codes, and read the warning Validate gives when a word is not one.
  • Simulate every branch before publishing.