Common mistakes
The mistakes below are the ones that bite people the first time they build a workflow.
1. No fallback on a Decision
Every Decision node must have a fallback edge — the route to take when no condition matches. Without it, a record can hit the Decision and get stuck with nowhere to go.
The Checklist tab will flag this with a red ✗ if any Decision is missing its fallback.
2. Approval Task without an assignee
If you forget to set an assignee, the task is created at runtime but no one is notified. The flow halts indefinitely.
Always pick either:
- A specific user (
assignee_user_id), - A role (
assignee_role), e.g. Supervisor, - A field on the record (
assignee_field), e.g. staff.supervisor_id, or - An assignment rule (e.g. Any HR Manager).
3. Two Start nodes
A workflow must have exactly one Start. The Builder won't stop you from adding two, but at runtime the engine picks the first one unpredictably.
4. A node with no outgoing edge (dead end)
Every non-End node must have at least one outgoing edge. An Action node without a connection means the flow stops there silently — looks "finished" in the audit trail but the next step never happened.
5. Trigger event not set
The most common "why isn't my workflow running?" cause. Check the trigger event field at the top of the workflow editor. For status changes, you also need to set the trigger field and the from / to values, otherwise the workflow fires on every update.
6. Editing a published workflow without versioning
When you change a published workflow, in-flight records keep running under the old version, but new records use the new one. This is intentional — you don't want to break runs that are halfway through — but it does mean changes don't apply retroactively. Test on a draft copy when possible.
7. Circular flows
You can connect a node back to an earlier one (e.g. a Decision loops back to an Approval). At runtime the engine breaks loops at a max iteration count to avoid infinite execution. If you genuinely need a loop, document why — and consider whether it should be modelled as multiple separate workflows instead.
When in doubt
Open the Checklist tab in the Assistant drawer. It runs every rule above plus a few others, and tells you exactly which node has the problem.