What the decision must mean
An approval workflow should make a decision traceable, not merely send reminders faster. Define the object being approved, the version the approver sees and the effect of approval. A request that changes afterwards may require a new decision; otherwise the audit history describes something nobody actually authorized.
Roles and alternatives
Start with roles and decision boundaries. A small team may only need a shared queue with recorded decisions. A larger workflow may need delegation, escalation and separation between requester and approver. Set an explicit policy for absence and expired requests. Automatic approval is a business rule requiring agreement, not a convenient default when nobody responds.
Walk through the change
In an illustrative purchase flow, an employee submits a supplier, amount and explanation. The manager approves that snapshot. If procurement changes the supplier, the request returns for review instead of inheriting the earlier approval. If the manager is away, a named delegate receives it with the delegation recorded. The interface shows waiting, approved, rejected and superseded states separately.
Check the failure paths
Email delivery is not evidence of approval. Nor should repeated button clicks create multiple purchase orders. Preserve a durable decision record and make the final action safe to retry. Test rejection, withdrawal, stale browser tabs and simultaneous reviewers. Restrict the ability to rewrite past decisions; corrections should explain what changed.
Write a decision record people can reconstruct
For the purchase example, separate the request from the decision and the purchase order created afterwards. Give each its own identity and retain the version that was reviewed. Record the acting person, their authority at that moment, the decision time and an explanation when the policy requires one. A chronological activity list should let a colleague reconstruct events without reading somebody else's inbox or guessing which attachment was current.
Walk through conflicting actions with the operations owner. Two reviewers may open the same version; the first decision can make the second screen stale. The second action should receive an explicit result rather than overwrite the earlier decision. Likewise, a request withdrawn during review must not become an order through a delayed click. Explain whether independent approvals are all required, whether one refusal ends the process and which changes reset previously collected approvals.
Separate policy failure from delivery failure. An approved purchase that cannot reach the purchasing system should stay approved with its execution marked pending or failed. Sending it back for another managerial decision would confuse authorization with transport. Retry only the outstanding operation, using an identifier that prevents duplicate orders. Give an operator a controlled repair path, preserve its history and confirm completion against the resulting purchase order. Review overrides periodically to discover whether the normal workflow is missing a legitimate recurring exception.
A small acceptance matrix
| Case | Evidence to inspect |
|---|---|
| Revised supplier after approval | The new version requires the agreed review; the previous decision remains attached to the earlier version and cannot authorize the replacement. |
| Two reviewers act together | Both users receive clear outcomes, with no silent overwrite and no extra purchase order from the losing action. |
| Notification fails after approval | The recorded decision survives; the pending delivery can be retried without reopening approval or repeating a completed purchase. |
| Temporary delegate expires | A later protected action checks current authority and refuses the expired delegation while preserving actions previously taken legitimately. |
Agree these rules
Who can request, decide, delegate and override? Which field changes invalidate approval? What happens when a deadline passes? Bring an ordinary request and a disputed exception to the automation discussion. Agree the policy before drawing its screens.