Approval workflows that match how you really decide

Good approval workflow design starts with one question: who actually says yes, and in what order? Most systems fail because they copy the org chart instead of the real decision, so requests stall behind someone who was never the decision-maker. Map the true sequence, give every gate a fallback, and the workflow holds.

Key Takeaways

• Model the decision, not the org chart — map who actually says yes, and in what order.
• Use serial gates for dependent decisions; parallel review only for genuinely independent checks.
• Give every gate a timeout, a delegate and a required rejection reason.
• The append-only audit trail is the product — design it before the screens.
• Threshold routing cuts most of the waiting by keeping small requests off senior desks.
• Start with your two busiest approval types; a generic workflow engine can wait.

What is approval workflow design?

Approval workflow design means mapping each real decision — who decides, in what order, and what happens when someone is away — into explicit system states. Built properly, it is a state machine: a request moves from submitted to approved, and every transition records an actor, a timestamp and a reason.

Approvals show up everywhere: leave, expenses, purchase orders, discounts, content publishing, access to production systems. The design work is the same each time — name the statuses, the transitions, the gates and the actors. Get that vocabulary right and every later choice gets easier.

Why do approval workflows break in real organisations?

Approval workflows break in production because they copy the org chart instead of the decision. Requests queue behind an absent approver, staff settle things over chat, and the record stops matching reality. The fix is structural: model who truly decides, then give every gate a timeout, a delegate and a rejection path.

The classic pattern: a director approves everything, so the queue becomes one person's inbox. Staff learn to settle purchases over chat, then retro-approve in the system seconds after a phone call. Nothing malicious — the workflow simply never matched reality. Latency is what teaches people to route around it.

When do you need purpose-built workflow support — and when you don't?

You need purpose-built workflow support once a process involves conditional routing, parallel reviews, delegation or a formal audit trail. If a six-person team approves three leave requests a week, a shared inbox and a spreadsheet are honestly enough. Adding states and notifications to trivial volume just creates a second system to maintain.

Watch for four signals: auditors asking who approved what, turnaround measured in days, approvals that stall whenever one person travels, and rules that shift with the amount involved. These are the moments a system shaped around your own rules earns its keep — the everyday work of custom internal software. Without them, don't build one.

How does an approval workflow actually work?

Under the hood, an approval workflow is a state machine plus a gate table. Each request carries a status; each gate names its actor set, permitted actions, timeout and fallback. Every transition writes an audit row and fires a notification, and a parallel gate stays open until all reviewers — or N of M — have acted.

If your team writes software, you already run one of these: GitHub's pull request reviews require a reviewer's approval before a merge is allowed, with every decision attributed and on the record. The same shape fits a purchase order. Write the transitions before you draw a single screen:

submitted       → manager_review    (auto, on submit)
manager_review  → finance_review    (manager approves)
manager_review  → rejected          (manager rejects — reason required)
finance_review  → approved          (finance approves)
finance_review  → rejected          (finance rejects — reason required)
any state       → cancelled         (requester withdraws)
manager_review  → finance_review    (after 48 h idle: escalate, don't drop)

Seven transitions. That is the whole specification — everything else is interface.

How do you design one step by step?

Design from observed decisions, never from software. Inventory each approval type and its weekly volume, shadow one real request end to end, then draw the states and transitions before touching a database. Define every gate with actors, timeout and delegate, build the audit record first, and pilot on one approval type.

1. List every approval type in the business, with weekly volume and today's typical turnaround.
2. Shadow one real request end to end, including the chat messages and phone calls around it.
3. Draw the statuses and transitions, including rejected, cancelled and returned-for-changes.
4. For each gate, fix the actor set — a named person, a role, or whoever a rule resolves — plus actions, timeout and delegate.
5. Design the audit record first: actor, timestamp, action, and the values the approver saw.
6. Choose notification behaviour — instant for waits, a daily digest for routine completions.
7. Pilot with one approval type, measure wait time per gate, then tune before rolling out.

Which gate pattern fits which decision?

Four gate patterns cover nearly every approval you will meet: a single approver, a serial chain, a parallel review, and threshold routing that selects the chain by amount or risk. Serial suits dependent decisions; parallel suits independent checks; thresholds keep small requests off senior desks, which is where most latency hides.

Whichever you pick, remember the queue is a screen someone opens fifty times a day, so the usual rules of designing a usable admin panel apply: show age, show what's stuck, make the common action one click.

Pattern	Best for	Watch out for
Single approver	Leave, routine expenses	One person becomes the delay — set a delegate
Serial chain	Dependent sign-offs: budget, then compliance, then payment	Every gate adds its own wait to every request
Parallel review	Independent checks done at once	Needs an all-complete or N-of-M rule to close
Threshold routing	Purchases and discounts by amount or risk	People split requests to stay under limits

How do you verify a new workflow — and debug a stalled one?

Verify a new workflow by pushing four request types through a staging copy: the happy path, a rejection, a timeout and a delegation — and confirm the audit table gains a row for each transition. When a live request stalls, debug in order: request state, gate actor resolution, notification log, audit trail.

The timeout path deserves special attention: an escalated request must land on a named human, not back into the same queue. Check the notification actually arrived — mail logs first, assumptions last. And the signature of a shadow process is an approval recorded seconds after a phone call. Decide deliberately whether the system is the record of truth or just a note, and write that into policy, not just software.

What are the security and audit essentials?

Treat every approval as a privileged action. Authorise it server-side, never by hiding a button; keep the requester out of their own chain; and make the audit log append-only — records can be added but never altered. Approvers should see only the fields their decision needs, and configuration rights must sit apart from approval rights.

Also export the trail in a format an auditor can read without your help. Separation of duties — requester, approver and configurator as three different roles — is what makes the record believable.

What does it really cost to run?

The build is rarely the expensive part. Running cost lives in keeping rules current as people change roles, keeping notification mail out of spam folders, and holding the discipline that every request goes through the system. Each extra gate adds waiting to every future request, so prune any gate you cannot justify.

Off-the-shelf tools trade build effort for per-seat licences and their own conventions — confirm current figures with the vendor before committing. Self-built rules age with the org chart, so somebody must own them. Budget engineer time for the boring parts: deliverability, role changes, the quarterly prune.

Which mistakes do we keep seeing?

The same handful of mistakes recurs in almost every broken rollout: copying the org chart, forgetting rejection paths, shipping gates without timeouts, sending approval links with no context, and building a generic engine before a second workflow exists. Each is cheap to avoid on paper and expensive to unwind after go-live.

• Copying the org chart instead of interviewing the people who actually decide.
• Rejection paths left undesigned, so refused requests dangle in a half-state.
• Gates shipped without timeouts, so one holiday stalls every request behind it.
• Approval emails with no amount, no requester and no link that works on a phone.
• Building a generic workflow engine before the second workflow exists.

What does this look like in a real company?

Picture a 40-person trading firm in Kathmandu. Purchases used to happen over WhatsApp messages and got reconciled at year end, when invoices went missing. The redesigned flow routes every request through one form: an automatic budget check, a manager gate, then finance, with a 48-hour timeout that escalates to the finance head.

Any trained office administrator can claim supply purchases below a set threshold; department heads approve their own budgets; finance sees everything above it. The general manager approves from a phone between site visits, which is why the approval screen must survive weak mobile data. Year-end reconciliation became a report instead of a hunt through chat threads.

Should you build, buy, or keep it simple?

Buy when the workflow is standard — expenses and leave fit tools such as Power Automate's approval actions or your ERP's built-in flows. Build when the workflow is your competitive process or must live inside a custom system. Keep it simple — one status field and email — whenever volume is low and rules rarely change.

We weigh this trade-off with clients constantly; our guide to custom software versus off-the-shelf walks through it in detail. The honest answer for most firms is mixed: buy the commodity approvals, build the two or three processes that are genuinely yours.

In short. Approval workflow design is unglamorous systems work that pays back every week: name the statuses, gates and actors before the screens; serial for dependent decisions, parallel for independent checks, and threshold routing wherever an amount decides who signs. Build the audit table before the forms. Pilot on your two busiest approval types, buy the commodity flows, and only build a generic engine once a third workflow proves you need one. The payoff is boring and real: fewer stalled requests, a record that survives audits, and decisions that no longer depend on whoever happens to be in the office.

People also search for

• What goes into the cost of a custom internal software build?
• When should we build software instead of buying an off-the-shelf tool?
• How do you design an admin panel people actually use daily?
• How do you build web tools that survive weak mobile networks?
• Which responsive design requirements belong in a development contract?
• Should internal business systems run on a VPS or cloud hosting?

Mapping how your company really decides is the hard half; the screens are the easy part. Our team can run that mapping with you, then design and build the workflow system around it — in your accounts and repositories, operable by your own people afterwards. Tell us which approvals slow you down, or read how we approach custom software development before you get in touch.