Approval Workflow Design: How to Structure Requests and Sign-Offs (2026)
How to design an approval workflow that people actually follow: the request form, routing rules, sequential and parallel sign-offs, delegation, escalation, statuses and the audit trail.
Key Takeaways
- Design the request so the approver never has to ask a question. Amount, reason, vendor or dates, budget line, attachments. Every follow-up question adds a day.
- Write the routing rule as a table before you automate it. Thresholds, approver per level, and what happens at each boundary. If the table is hard to write, the policy isn’t settled.
- Choose sequential, parallel or first-to-respond deliberately. Each has a different speed and control tradeoff. Microsoft’s Power Automate, for example, documents all of these as separate approval types.
- Plan for absence on day one. Delegates, escalation after a set time, and a named backup. Most stuck approvals are waiting on someone on holiday.
- The requester never approves their own request. Separation of duties is the core control. Build it into the rule, not into people’s good intentions.
Quick-Start Prioritization Framework
| Approval | Typical request fields | Typical routing | Pattern |
|---|---|---|---|
| Purchase request | Item, vendor, amount, budget code, reason, quote attached | Manager, then finance above a threshold | Sequential with thresholds |
| Time off | Type, start and end date, half days, cover arranged | Direct manager | Single approver with delegate |
| Software or SaaS request | Tool, cost per year, users, data it will hold | Manager, IT/security and finance | Parallel, all must approve |
| Access request | System, role requested, reason, end date | System owner | Single approver, time-limited |
| Expense claim | Date, category, amount, receipt | Manager, finance check | Sequential |
| Discount or pricing exception | Customer, deal size, discount %, justification | Sales lead, then finance above a level | Sequential with thresholds |
Every company has approvals: a purchase over a certain amount, a time-off request, a new software subscription, admin access to a production system, a discount above the usual limit. Most of them start life as an email that says “OK by me?” and end as a thread nobody can find six months later when finance asks who signed off. A good approval workflow is not complicated. It has a request that contains everything the approver needs, a rule for who approves, a clear set of outcomes, a plan for when the approver is away, and a record of what happened. This guide covers each piece with worked examples for purchase requests, time off and access requests.
Anatomy of an approval
Strip away the software and every approval has the same parts. Naming them helps you design each one on purpose.
- A request: the record being decided, with all the facts.
- A requester: the person asking, who should never be the approver.
- A routing rule: who must decide, in what order, based on what attributes.
- Decisions: approve, reject, or send back for changes, each with an optional or required comment.
- Timing rules: reminders, escalation and expiry.
- Outcome actions: what happens after approval (create a purchase order, update a calendar, grant access).
- A record: who decided what, when, and on what version of the request.
Design the request form first
Approvals stall when approvers lack information. The fix is upstream: a request form that collects everything the decision needs.
Ask what the approver checks
Sit with two or three approvers and ask what they look at before saying yes. For a purchase, it is usually the amount, the budget line, whether there is an existing vendor, and why it’s needed now. Those become required fields. Anything they never look at should not be on the form.
Use structured fields
Amount as a number with a currency, dates as dates, budget code as a list, vendor from a list with an “other” option. Structured fields make routing rules possible (“over 5,000 dollars goes to finance”) and make reporting possible later.
Require attachments where they matter
A quote for purchases over a threshold, a receipt for expenses, a data-processing summary for new software. Make the attachment required by rule rather than relying on the approver to send it back.
Lock the request once submitted
If the requester edits the amount after the manager approved, the approval no longer means anything. Either lock submitted requests or restart the approval when a key field changes.
Routing rules: who approves
The routing rule is the policy. Write it as a table, agree it with the people who own the policy (finance for spending, HR for time off, IT for access), then automate the table.
| Purchase amount (example policy) | Approvals required | Notes |
|---|---|---|
| Under 500 dollars | Direct manager | Within department budget |
| 500 to 4,999 dollars | Direct manager, then department head | Quote required |
| 5,000 to 24,999 dollars | Manager, department head, then finance | Two quotes required |
| 25,000 dollars and above | All of the above, then CEO or CFO | Contract review |
Route by attributes, not by names
Rules like “the requester’s manager” or “the owner of this budget code” survive reorganizations. Rules like “send to Maria” break the day Maria moves. Keep a manager field on each user and an owner on each budget code, and route from those.
Handle the edge cases explicitly
What if the requester is the department head? Skip to the next level, or route to their manager. What if the manager field is empty? Send to a named fallback, not into the void. What about splitting a 6,000 dollar purchase into two 3,000 dollar requests? Report on repeated requests to the same vendor in a short window.
Separation of duties
NIST describes separation of duty as the principle that no user should have enough privileges to misuse the system on their own. In approval terms: the requester can’t approve their own request, and ideally the person who approves a payment isn’t the one who creates the vendor.
Sequential, parallel and first-to-respond
When more than one person must decide, you have a choice of pattern. Microsoft’s documentation for Power Automate approvals lists these as distinct types: everyone must approve, first to respond, custom responses waiting for all or for one, and sequential approval. The names are useful whatever tool you use.
| Pattern | How it works | Good for | Watch out for |
|---|---|---|---|
| Sequential | Each approver in order; the next is asked only after the previous approves | Spending with escalating thresholds | Slow if any approver is away |
| Parallel, all must approve | Everyone asked at once; any rejection ends it | New software (manager, IT and finance each check different things) | One slow reviewer holds up everything |
| First to respond | Everyone asked; the first decision counts | A pool of on-call approvers, such as an IT access queue | Weaker control; record who decided |
| Custom responses | Approvers choose from options you define | Triage decisions (approve, approve with changes, escalate) | Keep the options few and clear |
A practical default
Sequential for money, parallel when different reviewers check different things, first-to-respond for operational queues. Avoid making everything sequential “to be safe”; every extra step adds waiting time without always adding control.
Decisions, statuses and notifications
Statuses should tell anyone, at a glance, where a request is and who it is waiting on.
A status set that works
Draft, Submitted, Waiting on [approver], Changes requested, Approved, Rejected, Cancelled, and for some flows Completed (the purchase order was raised, the access was granted). “Waiting on [approver]” is worth the extra effort: it ends the “who has it?” messages.
Send back, not just reject
Most requests that fail do so because of a missing detail, not a bad idea. A “changes requested” outcome with a required comment returns the request to the requester without starting from scratch.
Notify where people already are
Email with approve and reject links, a chat message, or a push notification on a phone. Approvers decide faster when they can act from the notification. Requesters should be told on every status change, not just the final one.
Absence, reminders and escalation
The commonest reason an approval is late is that the approver is on holiday, in back-to-back meetings or has left the company.
Delegation
Let approvers set a delegate for a date range. Record that the delegate approved on behalf of the approver, so the history stays honest.
Reminders and escalation
A reminder after one business day, a second after two, then escalation to the approver’s manager or a named backup after three. Pick the numbers to match how urgent the request type is; access requests for a new hire starting Monday may need hours, not days.
Expiry
Some approvals should lapse: a quote valid for 30 days, temporary admin access for a week. Store an expiry date and act on it automatically, revoking access or marking the request as expired.
The audit trail
The record of an approval is often worth more than the approval itself, because it is what you show an auditor, an investor’s due-diligence team or your own finance lead.
- Who submitted, and when.
- Every decision, by whom, when, and with what comment.
- Delegations and escalations, recorded as such.
- The version of the request each decision applied to.
- Outcome actions taken (PO number, access granted, calendar entry).
Three worked examples
Purchase request
Fields: item, vendor, amount, currency, budget code, reason, needed-by date, quote. Routing: the threshold table above, sequential. After final approval: notify the requester and finance, and create a purchase-order record. Report monthly: approvals by department, average days to approve, repeated requests to one vendor.
Time-off request
Fields: leave type, start and end dates, half days, cover arranged. Routing: the direct manager, with a delegate when away and escalation after two business days. After approval: add the absence to a shared team calendar. If payroll or an HR system tracks balances, display that balance on the request rather than calculating a second one.
System access request
Fields: system, role requested, business reason, end date for temporary access. Routing: the system owner, first-to-respond across a small pool of owners. After approval: create a task for IT to grant access, and a scheduled job to flag it for removal on the end date.
Common mistakes
- Automating an approval policy nobody has written down.
- Routing to named people instead of roles, so a reorg breaks every flow.
- Allowing edits after approval without restarting it.
- No delegate or escalation, so holidays stop the company.
- Only approve and reject, with no way to send back for changes.
- Comments optional on rejection, so requesters don’t know what to fix.
- Approvals buried in email with no searchable record.
- Too many sequential steps added “just in case.”
If you’d rather not build it yourself
If you’d rather not do this yourself, Floot, the AI app builder that publishes this site, can build an approval app from a description like the purchase example above, including threshold routing, email notifications, scheduled reminders and escalation, and a history table, published so only your invited colleagues can open it.
Frequently Asked Questions
What is the difference between sequential and parallel approval?
Sequential approval asks each approver in order, and the next is asked only after the previous approves. Parallel approval asks everyone at once. Sequential fits escalating spend limits; parallel fits cases where different reviewers check different things.
How many approval levels should a purchase request have?
As few as your controls require. Many small companies use one approver below a threshold, two in a middle band and finance or an executive above a higher amount. Write the thresholds down with finance before automating them.
What should happen when an approver is on vacation?
Let approvers name a delegate for a date range, send reminders after a set time, and escalate to their manager or a named backup if there is still no response. Record delegated and escalated decisions as such.
Can someone approve their own request?
They shouldn’t. Separation of duties means the requester and approver are different people. If the requester is normally the approver, route the request to their manager or a backup.
What should an approval audit trail include?
Who submitted and when, each decision with the person, time and comment, any delegation or escalation, the version of the request each decision applied to, and the actions taken after approval.
Sources
- Microsoft Learn, Get started with Power Automate approvals, 2026 https://learn.microsoft.com/en-us/power-automate/get-started-approvals
- NIST, Glossary: separation of duty, 2026 https://csrc.nist.gov/glossary/term/separation_of_duty
- OWASP, Logging Cheat Sheet, 2026 https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html