“The manager approved it” may not establish whether a request is ready to proceed. The approval could be in a chat while the file has changed since then. A useful system should show who approved what, under which conditions, and whether the team is still using that version.
Consider an illustrative purchasing request. The requester changes the delivery location after approval, while the receiving team has already downloaded the earlier file. This exposes the need to design roles, states and document versions together.
Define what approval actually means
Checking completeness, acknowledging receipt and authorising work are different responsibilities. Combining them under one “OK” button leaves the team uncertain about who must act and who made the decision.
The requester confirms the need
The requester should see the required information and check it before submission. If something necessary is missing, identify the field or document to correct. Sending incomplete work to an approver fills the queue without advancing the request.
The reviewer checks the supporting information
Some processes need a review before an approval decision. A reviewer may return an item for correction without having authority to approve it. Show that distinction in the interface and in the history.
The approver authorises the next action
The approver needs the relevant information, document version and supporting reasons. Where different conditions require different routes, select the route from the actual request data and make exceptions visible for human handling.
AI may help summarise a request or identify missing information. Approval affecting a business record must remain the decision of an authorised person; the system's summary should not substitute for that decision.
Give each state an operational meaning
| State | Meaning the team should agree |
|---|---|
| Draft | The requester is still preparing the information |
| Awaiting review | A reviewer must check completeness before routing |
| Awaiting approval | The request is with the appropriate decision-maker |
| Returned for correction | Specified issues must be corrected and resubmitted |
| Approved | The identified version is authorised for the next step |
| Cancelled or declined | This route has stopped, with a recorded reason |
“Returned for correction” should differ from “declined.” The former normally leaves an action for the requester, while the latter may end the request. A shared status makes it unclear whether to amend the information or begin a new request.
Approval may not be the final operational step. If another team must fulfil the request, record its receipt and link to the resulting work. The requester should not infer that an order has been placed or a service started simply because an approver accepted the request.
Decide when a change requires a new decision
Return to the delivery-location example. The team must decide whether the change affects scope, cost or another important condition, and who needs to review it. The system should not assume that a short text edit has a minor business effect.
Distinguish edits that leave the approved substance unchanged, such as certain internal notes, from changes that require reconsideration, such as recipients, items, quantities or important conditions. The process owner should define these rules; developers should not invent them.
Keep the earlier and revised versions and identify what changed. Approvers can then focus on the differences while retaining access to the full document. Record approval against the version actually reviewed, and let the receiving team see when a replacement is awaiting approval or an earlier version has been withdrawn.
If two approvers open the same request, or someone edits it while another person is reading, recheck the version before accepting the decision. A changed request should require another look rather than recording approval of information the person never saw.
Handle absence and failed handovers
Delegation should identify the substitute, scope and applicable period, while retaining the identity of the person who actually decides. A prolonged wait should trigger the agreed reminder or escalation route. Silence should not be treated as approval.
Distinguish work waiting for a person from work blocked by a system problem. An approved request that failed to reach its destination is different from one still awaiting a decision. It should be recoverable through the existing request instead of forcing the requester to create another item and risk duplication.
A useful history records the actor, role, time, information version, state change and relevant reason. Check the experience from the requester's, approver's and receiving team's perspectives. Each needs enough information to act, within their permitted access.
Before acceptance, test returned requests, post-approval edits, delegated decisions and failed handovers. The system should establish who is holding the work, why it is waiting and which information supported the decision. Those are the ambiguities an online approval process needs to resolve.
If approved requests must reach a legacy application, read about integrating systems without an API to assess supported transfer routes and destination checks.
Make approval status visible without another round of messages
Talvyn Labs designs and connects approval workflows with clear owners, approval steps and change history. Start with one request type that is difficult to track. We can map revisions, absent approvers and the handover to your existing systems before building.
Discuss approvals