Human approval checkpoints
Hand over the rules for stale approvals
The receiving team needs to know when an approved proposal can still run, when it needs review again and how to explain the difference to users.
In this article
Document what invalidates a decision
List the fields and conditions that approval depends on. These may include the proposal revision, target state, destination, reviewer authority and time limit. Explain which changes automatically expire the decision and which are revalidated at execution.
Use examples from the actual workflow. A changed delivery postcode and an unrelated internal note should not be treated as equivalent without a deliberate reason. Examples make the policy easier to maintain than a broad statement that approvals become stale when data changes.
Identify who owns the policy. Engineers can implement the dependency checks, but business owners need to decide which changes alter the meaning of the decision.
Show the complete record trail
Provide a synthetic proposal with its decision and execution record. Explain how to find the values reviewed, the person who decided and the result in the target system.
Include expired, rejected and uncertain examples. Support needs to distinguish a proposal waiting for a new reviewer from an operation that may already have executed. These states lead to different actions.
Document how notifications and old review links behave after a proposal changes. A reviewer following an old link should see the current status and should not accidentally approve a different revision.
Rehearse a delayed execution
Pause an approved test proposal, change a relevant target condition and resume it. Ask the receiving team to explain why execution was blocked and how the user obtains a new review.
Then repeat with a lost downstream response after a successful write. The team should reconcile the operation rather than sending it through a fresh approval and risking duplication. This exercise tests whether the handover preserves the distinction between authority and outcome.
Give operators supported actions for expiry, cancellation and recovery. Avoid procedures that require manually flipping an approval boolean in storage.
Maintain the policy as the product grows
New fields, external destinations and batch operations can change what a reviewer needs to see. Require those changes to revisit proposal binding, screen content and invalidation rules together.
Keep tests with the workflow owner and record who may accept exceptions. Review stale-approval incidents periodically to find rules that are too broad, too weak or poorly explained. A good handover allows the next team to preserve the meaning of a decision as the surrounding system changes.
Primary sources
OWASP: transaction authorisationOWASP: logging guidanceReferences checked 11 September 2026.