In this insight
An approval workflow should separate three things: a change someone proposes, the version another person reviews, and the decision that allows the change to take effect. When those things blur together, a reassuring green tick can hide a decision nobody actually made.
Imagine opening a revised estimate. A supplier has changed the delivery date and increased the price. The app notices both changes. That is useful. But noticing the changes is not permission to replace the agreed estimate. Detection answers what is different. Approval answers whether an authorized person accepts it.
Decide what approval actually means
Before drawing the screen, complete this sentence: approval allows this person to do this thing to this version, under these conditions. If the sentence is hard to finish, the software requirements are still incomplete.
For a fictional purchasing team, approval might allow a revised order to be issued. It may not authorize payment or confirm that goods arrived. Those are separate events. Calling all three states approved makes the screen simpler while making the business harder to understand.
The reviewer needs the original values, proposed values, reasons for the change and supporting evidence. Show meaningful differences rather than requiring a person to compare two long documents from memory. A change to delivery timing may matter more than ten spelling corrections.
Keep the proposal separate from the working record
Suppose an order is currently approved at 900 units. A proposed revision increases it to 1,100. While that revision is waiting for review, reports and downstream work must have a defined source of truth. Does the organization continue using 900, pause the order, or allow a limited provisional step?
There is no universal answer. The important part is that the answer is explicit. In our example, 900 remains the approved quantity until the revision is accepted. The proposed value appears beside it with a waiting-for-review label.
Rejecting the revision leaves the approved record intact and records the reason. Asking for changes returns the proposal for revision. Neither action should quietly erase the earlier decision. This separation makes disagreement manageable: a proposal can be useful even when it does not become policy.
Make the decision belong to one version
A supervisor opens revision two. While they read it, another person creates revision three. The supervisor presses Approve. Which version did they approve? If the application applies revision three, it has turned review into a guess.
A safer design checks that the reviewed version is still eligible before accepting the decision. If it has changed, the reviewer sees a clear message and the new differences. The earlier review can remain part of the history, but it does not silently authorize unseen content.
The same rule applies to identity and authority. Being allowed to approve when a page opened does not prove permission still exists when the button is pressed. Check the current decision boundary when the action is performed, not only when the controls are drawn.
Test more than the green tick
Start with a normal approval, then repeat the same submission. A double click or network retry should not create duplicate orders or notifications. Distinguish the decision record from its downstream effects so a failed email does not make an accepted decision appear to have vanished.
Next, test rejection, withdrawal and re-submission. Can a withdrawn proposal still be approved from an old tab? Does a new version need a fresh decision? If approval triggers an outside action, can cancellation still stop it, or has it already been sent?
Two reviewers may act at nearly the same time. The system needs a defined rule: first valid decision wins, everyone must agree, or different people approve different aspects. Record the result truthfully. Do not resolve a business disagreement through whichever database write happened to finish last.
Keep history useful without making it a maze
A good approval history explains what changed, who decided, which version they considered and what happened next. It should help a person understand the present record, not merely prove that the application stored many events.
For the revised order, the useful story is short: original accepted, increase proposed, delivery evidence attached, supervisor requested changes, revised quantity accepted. Link those events to the relevant versions and evidence. Preserve reasons that would otherwise disappear into messages.
This is also where AI can help without becoming the authority. It can summarize differences or flag missing evidence. Those suggestions still need an explicit route to acceptance. A confident explanation is not a substitute for a person's decision.
Model conversion exercise
Use this exercise with a real workflow and the people accountable for its outcome. Record disagreements as modeling questions instead of silently choosing an answer.
Take one approval in your organization. Write down what stays unchanged while review is pending. Then act out four cases: the content changes during review, the reviewer loses access, the request is withdrawn, and the approval button is pressed twice. Ask the team to agree on the visible result and any external action in each case. Turn unresolved answers into model questions before they become implementation assumptions.