Build approval workflows with clear authority and expiry
Define who can approve an action, what evidence they see and what happens when requests change or expire.
An approval workflow records permission for a particular action. It should identify the decision-maker, the exact proposal and the conditions under which that decision remains valid. Adding an approve button to an email is not enough if the underlying record can change before the action is executed.
Specify the decision and the decision-maker
Write the approval rule in business terms. Identify what is being authorized, who has authority and whether one person or several people must agree. Separate an informed reviewer from an authorized approver. A staff member who can verify an address may not be permitted to approve a commercial exception or expenditure.
Provide the facts needed for the decision, including the proposed action, relevant policy and supporting record. Avoid making the approver open several disconnected systems to reconstruct the request. Microsoft’s approval documentation demonstrates request, decision and follow-up steps; the organization still needs to define its own authority and escalation rules.
Bind approval to a version and a time window
Store the proposal version with the approval request. If a meaningful field changes, such as recipient, amount, scope or attachment, mark the previous decision as stale. Before execution, compare the current proposal with the approved version. Approval of one draft should not silently authorize a revised action with different consequences.
Define expiry, cancellation and reassignment. A request that waits beyond its useful deadline may need a fresh review, not an automatic approval. When someone is absent, assign the request to an authorized alternate rather than forwarding an unrestricted link. Record who actually decided, including delegated decisions, so the history remains understandable.
Keep decision status separate from execution status
Use distinct states for awaiting approval, approved, rejected, expired, action pending and action completed. If an approved action fails technically, repair or retry that action under the documented policy. Do not create a fresh approval for every harmless retry, but do request a new decision when the proposal itself changes.
Test concurrent responses, expired requests and edits made while approval is pending. Ensure that an approval cannot be applied twice to duplicate a consequential action. Review the audit history with the process owner and confirm that it answers who approved what, on which evidence, and what happened afterwards.
Practical checklist
- Define approval authority and delegation rules.
- Attach the exact proposal and supporting evidence.
- Invalidate decisions after meaningful proposal changes.
- Track approval and execution as separate states.
Illustrative setup: a service exception
A customer asks for work outside the standard package. The coordinator submits a proposed scope exception to the owner. While approval is pending, the customer adds another requirement. The workflow marks the proposal as changed and requests a new decision instead of applying approval for the earlier, smaller scope.
Common questions
Can approval happen inside email or chat?
Yes, if the implementation reliably identifies the approver, binds the response to the correct request and enforces the same authority rules as the main application.
Should overdue requests be approved automatically?
Only if that is an explicit, appropriate business rule. For consequential actions, expiry or escalation is usually a safer starting design than treating silence as agreement.
Further reading
Start with your actual workflow.
Turn the useful parts of this guide into a focused project brief.
Shape your project