Approval is a deceptively respectable word. It sounds prudent, organised and faintly reassuring, like a clipboard with rounded corners. Yet in many products an approval workflow is simply a queue wearing a tie: work enters, context evaporates, and everyone waits for someone senior enough to feel nervous in public.
The problem is rarely that organisations have approvals. Some decisions genuinely require authority, separation of duties or specialist judgement. The problem is that approval is treated as a generic interaction rather than a specific decision. A request is “submitted”, an approver is “notified”, and a button marked Approve appears. The software has technically completed its duties. The humans are left to work out what they are approving, why they were chosen and whether declining will summon a small committee.
Good approval design does not begin with the buttons. It begins with the risk.
An approval is a decision, not a status
Teams often model approval as a neat sequence of states: Draft, Submitted, Approved, Rejected. This is convenient for databases and wonderfully uninformative for people. It says where the record is, but not what judgement is required.
Consider a charter quote that exceeds a margin threshold, a supplier invoice with an unusual tax treatment, or a contract containing a non-standard clause. Each may require approval, but the decisions are different. One asks whether the commercial trade-off is acceptable. Another asks whether the financial treatment is correct. The third asks whether the organisation is willing to accept a legal obligation. Sending all three through the same cheerful “Please approve” pattern turns expertise into ceremony.
The interface should state the decision in plain language. What changed? What rule or threshold was triggered? What is the consequence of approving? What happens if the approver does nothing? When those questions are absent, people recreate the answer through messages, attachments and meetings. The approval screen becomes a ceremonial doorway while the actual decision happens elsewhere.
Design around the exception
Routine work should not require theatrical supervision. If every ordinary request needs manual approval, the organisation has probably encoded mistrust rather than risk.
The useful question is not “Who approves this type of record?” It is “Under what conditions does this record need additional judgement?” That changes the design. Standard cases can move according to agreed rules. Exceptions can be routed to people with the right authority and context. The workflow becomes proportional.
Thresholds matter, but they should be legible. A user should understand why an approval was triggered rather than encountering an unexplained gate. “Director approval required” is a dead end. “The proposed margin is 2.4 percentage points below the commercial floor” is a reason. It allows the requester to correct the work, add justification or deliberately escalate it.
This distinction is more than helpful copy. It affects behaviour. Hidden rules train people to submit and hope. Visible rules help them prepare better decisions.
The approver needs a decision brief
Approval screens often present the entire record because completeness feels responsible. The result is a digital loft: everything is present, although finding the important thing may require protective clothing.
Approvers need a brief, not a data dump. The interface should foreground what is unusual, what has changed since the last review, which evidence supports the request and what the requester recommends. Supporting detail should remain available, but it should not compete equally for attention.
A useful decision brief might include:
- the decision being requested; - the reason approval is required; - the material financial, operational or legal effect; - the assumptions and unresolved issues; - changes since any previous submission; - the requester’s recommendation; - the deadline and consequence of delay.
This is progressive disclosure doing grown-up work. It does not hide complexity. It arranges complexity around the judgement being made.
Rejection is not a destination
Many products treat rejection as the dramatic opposite of approval. The record turns red, the requester receives a notification, and the workflow stops with the confidence of a Victorian railway buffer.
But rejection usually means one of several things: the proposal is unacceptable, the evidence is incomplete, the request went to the wrong person, a condition must change, or the approver needs clarification. These require different next steps.
A useful decline action asks for a reason and offers a structured route forward. “Return for changes” should identify what must change. “Request information” should keep the decision open and assign the question. “Decline” should be reserved for a genuine no, with the consequences made clear. A request should not lose its history simply because it needs another iteration.
The language matters. Rejection sounds final and personal. Returning a request with a clear condition turns disagreement into work. Enterprise software contains enough accidental melodrama already.
Parallel approval is not automatically faster
When sequential approval becomes slow, the obvious response is to ask everyone at once. This can reduce elapsed time, but it can also produce four conflicting opinions and no clear owner.
Parallel review works when reviewers are assessing independent concerns. Finance can examine credit exposure while operations checks feasibility. It fails when later judgement depends on earlier decisions or when nobody knows whose objection takes precedence.
The product should show the decision structure. Are all approvals required? Is one sufficient? Can a specialist veto? Does a senior approval supersede another? What happens when reviewers disagree? These are governance rules, not interface decoration. Leaving them implicit turns the activity feed into constitutional law.
Where reviews are independent, present them as separate questions. Where they are dependent, make the order visible. Where escalation is possible, state who owns the final call. A tidy row of avatars is not a decision model.
Delegation needs boundaries
Approvers go on leave, change roles and occasionally spend a week in meetings discussing efficiency. Delegation is therefore essential. It is also dangerous when implemented as “let someone else be me”.
Delegation should specify scope and duration. A manager might delegate approvals below a value threshold for two weeks, while retaining high-risk decisions. A legal reviewer might delegate a region but not a contract category. The interface should make delegated authority visible to requesters and auditors without requiring an archaeological expedition through account settings.
Temporary authority should expire automatically. Decisions should record who acted, whose authority they used and what delegation rule applied. This is not administrative fussiness. It protects both the organisation and the person asked to act.
Reminders should preserve dignity
Approval workflows create notifications with the enthusiasm of a smoke alarm near a toaster. A request is submitted. A reminder follows. Then another reminder reminds the approver about the previous reminder. Soon everyone has learned that notifications are ambient weather.
Useful reminders are risk- and time-aware. They indicate what is waiting, why it matters and when action becomes consequential. They should consolidate related work rather than generating one message per record. They should escalate deliberately, not simply become louder.
The requester also needs honest visibility. “Pending approval” is not enough. Show who owns the decision, when it was requested, whether the approver has asked for information and what escalation path exists. Avoid exposing surveillance theatre such as “seen three minutes ago” unless it genuinely helps the workflow. Knowing that someone opened a request does not make the aircraft fly sooner.
Preserve the reasoning
An approval without reasoning creates an audit trail of button presses. Six months later, the organisation can prove that Martin approved the exception but not why Martin thought it sensible.
Not every routine decision needs an essay. The system can capture reasoning proportionately. Standard approvals may inherit the request’s stated rationale. Exceptions, overrides and declines should require a concise explanation. If evidence or a discussion informed the decision, link it to the record rather than leaving it stranded in a private channel.
This history should remain readable. A timeline needs to say more than “Status changed from Submitted to Approved”. It should connect the request, conditions, questions, changes and final decision as a coherent account. An audit log is most valuable before the audit, when a colleague is trying to understand what happened.
Measure waiting, not clicking
Approval analytics often celebrate throughput: number approved, percentage completed, average button-press time. These are easy to count and poor at explaining the work.
Measure where decisions wait, how often requests return for missing information, which rules trigger unnecessary review and how frequently authority is unclear. Compare the time spent awaiting judgement with the time spent preparing it. Look for approvals that are always granted without changes; they may be candidates for automation or policy redesign. Look for repeated declines from the same missing evidence; the submission experience probably needs improvement.
The goal is not to make approvers click faster. It is to reduce avoidable uncertainty while preserving necessary control.
Approval should create momentum
A good approval workflow leaves everyone clearer than it found them. The requester understands the decision and any conditions. The approver sees the relevant evidence and authority. The organisation retains a useful account. The next step begins automatically, without somebody forwarding a screenshot to ask whether the thing is “properly approved now”.
This requires product teams to resist the generic pattern. Do not start with a status field and two buttons. Start with the decisions, risks, thresholds, authorities, exceptions and consequences. Then design the interface that makes those things legible.
Approval is not where work should go to wait. It is where uncertainty should be converted into an accountable decision – and then politely get out of the way.
See it in practice
Approval design becomes especially tangible in my Aerios carrier marketplace case study, where commercial, contractual and operational decisions need clear ownership. For a useful technical counterpoint, the OWASP Authorization Cheat Sheet explains why permissions, validation and logging belong in the design of consequential actions.
