What a human approval step should actually do.

A button is not enough

Imagine an example notification that says an invoice is ready and offers an Approve button. The reviewer still needs to know what was checked, what will happen next and whether anything changed. Without that context, the button merely moves responsibility to a person who has not been equipped to use it.

Start with the decision, not the interface. Is the person approving a draft, a data update, an external message or a financial action? These permissions are different. A useful review screen should say exactly which action is waiting and what approval authorizes.

Show evidence beside the proposed action

A reviewer should not have to open five systems to understand one exception. Present the relevant source, the proposed output and the difference that caused the hold. Keep the source accessible, and distinguish recorded facts from an AI-generated interpretation.

In an illustrative supplier workflow, matching an invoice to a purchase order does not resolve a changed bank account. The review should expose the change and route it to the person authorized to check it. An AI-generated confidence label is not a substitute for a verification procedure. The operator still needs an agreed way to confirm the information.

Define the permission before asking for approval

Create an approval matrix for the workflow. Some actions can be read-only. Some can prepare drafts. Some can write to internal systems after validation. Others must wait for an authorized person. Keep permission narrow enough that approving one record does not silently authorize a different action.

For each permission, name an owner, the evidence required and the expiry conditions. If a reviewed record changes before execution, consider whether the approval remains valid. A record version or summary of the approved fields helps prevent the system from executing something different from what the reviewer saw.

• What action will happen after approval?
• Which source and record version support it?
• Who is allowed to authorize it?
• What changed or remains uncertain?
• How can the reviewer reject, correct or escalate it?

Make waiting a valid state

A person may be unavailable or need more information. Define how the workflow waits, who is notified and when an unresolved case is escalated. Do not let an unanswered request quietly become approval. A timeout should have an explicit outcome appropriate to that process.

The goal is not to route every trivial action through a human. That can create review fatigue and a new bottleneck. Use the matrix to reserve attention for decisions where it matters, and make routine checks consistent. Review the queue over time to see whether the same avoidable exception keeps appearing.

Record the decision and its result

An approval record should let an authorized colleague understand what happened later: the proposed action, relevant source, decision, approver, time and execution outcome. If the downstream action fails, show that distinction. Approved does not mean successfully completed.

Test a rejection, a correction, an expired request and a duplicate click before using the flow on real work. Decide whether the approved action can be retried safely and how duplicate execution is prevented. Keep retention and access appropriate to the sensitivity of the information; this article proposes an operating pattern rather than a legal compliance standard.

The Human Approval Matrix in the Operations Library gives you a starting template. Replace its examples with your actual authority rules and have the process owner review them before a pilot begins.