“AI wants to update a customer record. Approve?” is not enough information to make a decision. The reviewer does not know which customer, what will change, or whether the update is based on a confirmed request.
An approval step should answer those questions before it asks for a click. Otherwise the reviewer becomes a rubber stamp.
Show the action, not just its summary
For a record update, show the system, record, current value, proposed value, and evidence. For a message, show the recipients, subject, final body, and any attachments. Make clear whether the action stays internal or goes to an external party.
In an illustrative workflow, “Update delivery date” becomes: “Change the date on order 847 from 12 November to 14 November, based on the supplier's confirmation. This updates the internal order only; it does not notify the customer.” If notification is also proposed, review it as a separate action.
Make approval specific
The approval should apply to the version of the action the person reviewed. If the recipient, date, or attachment changes afterward, present the changed proposal for review again. Before executing, check that the record is still the expected version and that the reviewer has the authority to approve the action.
A confirmation button is not an authorization boundary by itself. The service that performs the action should enforce those checks independently of the model and the screen.
Give reviewers more than two choices
Offer a useful way to edit a draft, request clarification, reject the action, or escalate it. If rejecting creates a backlog, tell the reviewer where it goes and who owns it. If the action cannot easily be reversed, say so before approval.
For batches, show the total and let reviewers inspect exceptions. Approving a set of routine updates should not quietly authorize one unrelated external message in the same batch.
Tell the reviewer what actually happened
Distinguish “approved,” “executing,” and “completed.” An approval confirms a decision; it does not prove the destination accepted the change. If an external request times out, show that the outcome is uncertain and direct the reviewer to the recovery procedure rather than asking them to approve it again.
Run a five-minute review test
Give a teammate a proposed action without explaining it verbally. Ask them to identify the target, what changes, the source, the consequence, and what to do if the evidence is wrong. Then test what happens if the proposal changes after approval.
If they cannot answer from the interface, add the missing context before adding more automation.
Read our guide to reliable retries for what happens after execution starts. For help designing a review step, contact Storm Nova Labs.
