Building an Approval Workflow That Actually Works
Most approval workflows fail because they're either too rigid (people work around them) or too loose (nobody actually approves). Here's how to design ones that survive contact with reality.
Building an Approval Workflow That Actually Works
A workflow that is bypassed is worse than no workflow — it gives the illusion of control while delivering none. This guide is about designing workflows that people use, not workflows that exist on paper.
The five questions to ask before designing
- What's the worst that happens if this isn't approved? If “nothing material”, the workflow may not be needed.
- Who has the authority and the information to approve? Often these are different people. Both must be in the loop.
- What's the realistic SLA? Not the aspirational one. The realistic one. Design to that.
- What happens when the approver is unavailable? Always. Design the delegation path.
- How will we know if the workflow is working? Define the metric before you build.
The four common failure modes
Failure mode 1 — The CFO bottleneck
Every approval ends up at the CFO regardless of value. The CFO becomes the bottleneck; the organisation grinds.
Fix: Threshold-based conditional routing. Under KES 100K, line manager approves. KES 100K-500K, department head. Over KES 500K, CFO. Adjust thresholds quarterly based on actual volume distribution.
Failure mode 2 — The serial chain
Approval requires Person A then Person B then Person C, in sequence. Total cycle time is the sum of three response times.
Fix: Use parallel approval where possible. If A, B, and C can each independently approve, route to them in parallel; collect all responses.
Failure mode 3 — The “everyone CC'd, nobody decides”
The approval is sent to a distribution list. Everyone assumes someone else will approve.
Fix: Single named approver per node. If the approval is meant to be collective, use a “majority of named approvers” rule, not a CC-everyone scattergun.
Failure mode 4 — The silent rejection
Approver rejects without explanation. Submitter doesn't know why. Iterates randomly. Cycle repeats.
Fix: Make rejection comments mandatory (Papyrus enforces this). Rejection is more expensive for the approver than approval, deliberately.
The workflow design checklist
Before deploying any workflow:
- Each step has a single, named approver (or a deterministic rule for resolving)
- Each step has an explicit SLA
- Each step has a delegate path for OOO scenarios
- Conditional branches (if any) use extracted document metadata, not human judgement
- Parallel nodes used where serial isn't required
- Rejection requires a comment
- Approval optionally allows a comment (encourage it)
- Escalation chain defined for SLA breach
- Notifications configured per step (in-app + email at minimum)
- Email approval link works for non-Papyrus-native users
- Workflow analytics enabled so you can measure later
SLA design
The realistic SLA framework:
- Same-business-day approvals: Reserve for genuinely urgent (security incident response, emergency procurement). Most “urgent” isn't.
- 24-hour SLA: Routine high-volume (invoice approval under threshold, leave requests under 5 days)
- 48-hour SLA: Standard commercial (contract review, mid-value invoices, departmental policy)
- 5-business-day SLA: Strategic (large contract execution, capital approval, hiring sign-off)
Allowances:
- Add 24h to any SLA crossing a weekend
- Add the holiday duration if it spans a Kenyan public holiday
- Don't tell users you've done this — they should see the deadline date, not the math
Escalation chain
When the SLA is missed:
- At 80% of SLA: Reminder to the approver
- At 100% of SLA: Escalation notification to the approver's manager
- At 150% of SLA: Tenant Admin alert; workflow flagged as breached
- At 200% of SLA: Workflow Designer reviews; either re-routes or marks the approver as a structural bottleneck
The chain is not punitive — it's informational. Bottleneck identification is a data-driven exercise.
What to measure
After 30 days of operation, every workflow has analytics:
- Median cycle time: how long from submission to completion
- SLA compliance rate: % of instances meeting SLA
- Per-approver response time: identifies the structural bottleneck
- Rejection rate: too high = submissions are sloppy; too low = approval is rubber-stamping
- Escalation rate: high = SLA is too tight or coverage is inadequate
- Re-submission rate: rejected → revised → re-submitted; measures iteration cost
Review monthly. Adjust the workflow when the numbers tell you to.
When to retire a workflow
Sometimes the right answer is to remove the workflow:
- Rejection rate consistently under 2%? The approval is a rubber-stamp; consider replacing with notification-only
- Submitters routinely bypass it (e.g., emailing the approver directly)? The workflow isn't trusted; investigate why
- SLA compliance below 50% despite tuning? The workflow may be structurally infeasible
Workflows are tools, not artifacts. They earn their keep.