Why patterns matter
Every business process looks different on the surface. An invoice approval looks nothing like an employee offboarding. But underneath, they share structural DNA. Learning to recognise that DNA lets you build new workflows faster and avoid common failure modes.
Here are the five patterns we see in almost every operations workflow.
Pattern 1: Linear approval chain
Structure: Task → Approve → Approve → Approve → Done
Where it appears: Purchase orders, contract sign-off, policy exceptions
The rule: Keep approval chains as short as possible. Every additional approver adds latency and reduces accountability. If three people all need to approve, ask whether the third approver adds information that the first two didn't already have.
Anti-pattern: Sequential approval where parallel approval works fine. If finance and legal both need to sign off, run them simultaneously unless there's a dependency.
Pattern 2: Parallel task fan-out
Structure: Trigger → [Task A + Task B + Task C simultaneously] → All complete → Continue
Where it appears: Onboarding (provision accounts + order hardware + set up tools), event planning, product launches
The rule: Use this whenever tasks are independent. A common mistake is running parallel tasks sequentially because "it's easier to track" — that's a workflow tool problem, not a process design choice.
Watch out for: Partial completion. If one parallel task fails or stalls, what happens to the others? Build your failure path before you launch.
Pattern 3: Conditional branch
Structure: Input collected → if/else → different paths
Where it appears: Expense approvals with different thresholds, support tickets by severity, hiring workflows by seniority level
The rule: Name your conditions explicitly. "If amount > $5000" is clear. "If the request is large" is not. Ambiguous conditions cause inconsistent execution and audit headaches.
Common mistake: Building too many branches. More than 4–5 branches usually means you're encoding a decision that should belong to a person, not a rule.
Pattern 4: Escalation loop
Structure: Assign task → wait X hours → if not completed, escalate to backup → if still not, escalate again
Where it appears: Approval flows, support resolution, compliance deadlines
The rule: Every human step should have an escalation path. "Assigned to Alice" is incomplete. "Assigned to Alice; escalates to her manager after 24 hours" is a complete step definition.
Build it now, not later: Escalation is always "we'll add it later" until a missed deadline causes an incident. Add it at design time.
Pattern 5: Event-triggered sub-workflow
Structure: Main workflow → fires a sub-workflow when a condition is met → sub-workflow runs independently
Where it appears: Onboarding that triggers a 30-day check-in sequence, contract approval that triggers a billing setup, incident response that triggers an escalation tree
The rule: Sub-workflows are powerful but create visibility debt. If you trigger 3 sub-workflows from one parent, make sure your team can see all 4 in one view. In Atomic Work, the parent run shows all child runs inline.
Putting it together
Most real processes are compositions of two or three of these patterns. An invoice approval is Pattern 1 (approval chain) with Pattern 4 (escalation) and Pattern 3 (different thresholds). An onboarding is Pattern 2 (parallel tasks) with Pattern 5 (sub-workflow for the first 90 days).
Build the pattern, not the one-off. Reusable patterns mean each new workflow you build takes less time than the last.