How to design an approval workflow people actually follow

An approval workflow needs to answer a few everyday questions clearly: who decides, what they are deciding and what happens while the request waits. Begin with those rules before selecting buttons, notifications or integrations. A workflow people can explain to one another is easier to review when an unusual request arrives.

Use the guidance below for one specific approval path, such as a purchase request. Keep other paths separate until their rules are clear. Content review may involve revisions to a document, while a purchase decision may depend on budget ownership. Giving both the same status names does not make their decision rules identical.

Define the decision and its boundaries

Write down exactly what approval authorizes. For a purchase, it might authorize ordering a specified item up to an agreed amount. Identify what approval does not complete, such as placing the order or confirming delivery, in the operating instructions. Those later actions need their own owners and visible states.

Name the information required for a decision. A purchase request might need a description, business purpose, amount and budget. A contract request might need the document version and the parties involved. Ask an actual approver which information changes the decision, then make those fields easy for the requester to supply.

Decide what happens if the request changes. A material change after approval should follow a stated review rule. The team should define which changes matter for its process, rather than rely on a requester to interpret a vague instruction to seek approval again “when necessary.” Keep previous versions available in the decision record.

Set thresholds that can be applied consistently

Approval thresholds can depend on amount, category or another documented condition. Choose inputs the workflow can identify reliably. If a rule depends on whether something is “strategic,” define who makes that classification and where the reason is recorded. An undefined label moves the uncertainty into the routing logic.

Write boundary cases explicitly. If the buyer defines an amount threshold, state which route handles a request exactly equal to it. State how the process handles a revised amount and whether related requests need joint consideration under the organization's policy. These are policy decisions for the responsible owner, not universal numbers to copy from another company.

Test the rules using a small set of sample requests that cross each boundary. Include an empty field, an unrecognized category and a request whose budget owner is unavailable. Each should land in a visible exception queue or return for correction. A request should not disappear because none of the ordinary rules matches it.

Give each step a single accountable owner

A group can advise on a decision, but one role should be responsible for moving the request out of each pending state. Name that role in the workflow. If several approvals are genuinely required, show them as distinct decisions and explain whether they occur together or in sequence.

Avoid assigning a request to an entire department with no rule for who picks it up. If a shared queue is necessary, define how a person claims a request and who monitors unclaimed work. The requester should be able to see the current owner or the role responsible for assignment.

Consider where duties should be separated. NIST SP 800-53 Rev. 5, control AC-5, addresses identifying and documenting duties that require separation and defining access authorizations to support that separation. Applied to this design exercise, ask whether the requester should also be able to approve the same request or change the rule that routes it. Referencing AC-5 here does not establish compliance; the organization must assess its own responsibilities and risks.

Plan delegation and timeouts

Define who can delegate a decision and when delegation expires. A temporary substitute should have the authority needed for the assigned decision. Record the original owner and the acting delegate so someone reviewing the history can understand what happened. Decide whether the original owner can still act while delegation is active.

A timeout should cause an explicit event. It might remind the current owner, alert a process manager or assign the request to an authorized substitute. Choose the interval according to the work and the team's capacity. Silence should have a documented meaning; it should not accidentally become approval because someone forgot to configure the next state.

Keep escalation separate from expanding authority. A manager being notified of a delay does not automatically mean that manager may authorize the request. Write down who can make the decision when the usual approver is absent. Include an exception path for cases where no authorized substitute is available.

Make status useful to the requester

Use status labels that explain the next action. “Waiting for budget owner” tells the requester more than “in progress.” “Returned for supplier details” should link to the missing information and the person responsible for providing it. Show the last meaningful event alongside the current state.

Decide which channel holds the authoritative request. Notifications can point people to that record. If email replies are accepted as decisions, the system needs a defined way to identify the actor, associate the reply with the correct version and record the outcome. Otherwise, direct the approver to the request itself so the decision stays attached to its context.

Keep a decision history that answers questions

For each decision, retain the actor, time, request version and outcome. Record the reason for a decline or return, and preserve a meaningful history of routing changes. Someone reviewing the request later should be able to distinguish an approval from a comment saying that an item looks reasonable.

Set access according to the information involved. Request visibility, approval authority and administration are different permissions. Decide who can correct an error in the record and how that correction will be shown. Also establish retention and export arrangements appropriate to the organization, rather than keeping records indefinitely by default.

Worked hypothetical example: a weak purchase path

An employee emails a proposed purchase to a managers' group. One manager replies “fine,” another asks which budget applies and a third forwards the message to finance. The employee treats the first reply as approval and places the order. Finance later receives a different attachment showing a changed amount.

The weakness is specific. The group has no assigned decision owner, the approval applies to no clearly recorded version and the request has no visible final state. The changed amount has no defined route. Adding more reminder emails would preserve all of those ambiguities.

Worked hypothetical example: an improved path

The same employee submits the item, amount, purpose and budget through a request record. The workflow assigns the named budget owner. Requests meeting the organization's additional-review rule then move to a separately identified finance approver. The interface shows which decision is pending and the person responsible for it.

The budget owner returns an incomplete request with the missing field identified. The employee revises and resubmits it under the same reference. If the budget owner is away, an authorized delegate acts during a recorded delegation period. An overdue decision alerts the process owner according to the chosen timeout rule; it does not automatically authorize the purchase.

Once all required decisions are recorded, the request moves to the ordering owner. A changed amount follows the documented reassessment rule before ordering. The order record points back to the approved version. Completion means the defined purchasing action has occurred, so a requester can distinguish permission to proceed from actual fulfillment.

Use this checklist on one existing path

• State the action approval authorizes and the information required.
• Write each routing condition, including its boundary and fallback.
• Assign one accountable owner to every pending decision.
• Define delegation authority, expiry and timeout behavior.
• Show the requester the state, next owner and any missing information.
• Attach each decision to an actor and a request version.
• Test a returned request, an absence and a change after approval.

Ask the requester and approver to walk through those cases together. Where their answers differ, resolve the rule before publishing the workflow. Rewrite one existing approval path with the checklist, then run a limited pilot with a named owner for questions and corrections.