Business Approval Workflow Patterns: Delegation, Deadlines, and Evidence Approval is not a button beside a record. It is a controlled transition with an au...
Business Approval Workflow Patterns: Delegation, Deadlines, and Evidence
Approval is not a button beside a record. It is a controlled transition with an authorized decision-maker, a stable version of the request, an outcome, and evidence. Expense claims, content publication, procurement, and access changes may share an engine, but their thresholds and separation-of-duties rules differ. Have each process owner approve its policy before automating it.
Represent the request and its version
Store the submitted payload or a versioned reference to it. If the requester changes amount, supplier, or scope after submission, decide whether approvals reset. Never let an approver sign one version while the final action applies a different one. Use explicit states such as draft, submitted, awaiting approval, approved, rejected, cancelled, and executed. Validate allowed transitions on the server.
Model approval steps with role or named approver, order, deadline, and whether one or all participants must approve. Parallel steps need a clear completion rule. Escalation should notify the right person without silently granting them authority. A delegate's access should have a start and end time, reason, and audit trail.
Prevent conflicts of interest
Define whether a requester may approve their own request. For high-impact changes, use separation of duties and require a second role. Check permissions at the time of the action, not only when the task is assigned: users can change teams while a request waits. A stale approver link must not bypass current policy.
Record decision, comment, actor, timestamp, and the exact request version. Keep rejected and cancelled requests visible to authorized users. If a decision is reversed, append a new event and explain the transition rather than editing away history.
Make execution reliable
Approval and execution are different. A payment can be approved but fail at the gateway; a published article can be approved but fail its deployment. Track execution state and retries separately. Use an idempotency key for external operations so a retried job does not repeat a transfer or email. Notify users of meaningful changes, but make the database the source of truth rather than email delivery.
Test conflicting decisions, expired delegates, changed request amounts, double clicks, queue failures, and approver removal. The workflow is trustworthy when an auditor can reconstruct who approved exactly what and when. See our web development service for custom approval systems.
References