How to Design an Approval Workflow for a Custom App
A practical method for designing an approval workflow: states, routing, escalation and audit trails, plus how to decide how many approval steps you need.
An approval workflow is the set of rules that decides who must sign off on a request, in what order, and what happens when nobody responds. To design one for a custom business application, define the states a request can sit in, the conditions that move it between those states, the roles allowed to act at each step, and the escalation path when a deadline passes. Screens, notifications and dashboards are presentation layers over those four decisions.
What should an approval workflow actually control?
Approval workflow design starts with four decisions: who can submit a request, who must approve at each level, which conditions let a step be skipped, and what happens when a request stalls. Everything else follows from those four.
Write the process down as it exists now, including the exceptions people currently handle over chat or by phone. Most teams find that roughly two thirds of their approval volume needs one approver, and that the remaining third carries almost all the complexity. Designing for the simple case first keeps the application usable, and adding a rule for the rare case later is easier than untangling a workflow that assumed every request was complicated.
Two terms are worth fixing before you go further. Escalation is the automatic reassignment or notification that fires when a step sits untouched past its deadline. Delegation is permission for one person to act on another's behalf for a set period, recorded against the real actor's name.
Which routing model fits your process?
Routing decides which person or role receives a request at each step. The three patterns worth knowing are sequential, parallel and threshold, and each trades speed against control differently. Sequential is the simplest to explain and the slowest to run.
The cycle times below are rough planning estimates, not measured benchmarks, and they assume a request that is not unusually complex.
| Routing model | How it works | Typical elapsed time | Relative build cost | Fits well when |
|---|---|---|---|---|
| Sequential | One approver per step, in a fixed order | 2 to 5 business days across three steps | Lowest | Spend limits, headcount changes, simple sign off |
| Parallel | Every approver sees the request at once, and one rejection ends it | Roughly half the sequential time | Moderate | Legal, finance and security are checking different things |
| Threshold (quorum) | Approves once a set number of responses arrives | Set by the slowest responder | Moderate | Committee decisions, credit or risk sign off |
| Value based | Adds or skips a step when an amount or attribute crosses a limit | Sequential time plus one step | Highest | Discounts, procurement, anything with a money threshold |
Value-based routing is the pattern most teams end up needing. The rule reads an attribute on the request, usually an amount, a discount percentage or a customer tier, and decides whether an extra step applies. Keep those thresholds in configuration rather than in code, because finance will move them, often once a quarter.
How many approval steps should an approval workflow have?
Most approval workflows need one or two steps: a manager check, plus a second approver only when a value threshold is crossed. Each extra step adds roughly 8 to 12 hours of waiting time.
A five-step chain can turn a two-day decision into a two-week one, and the delay compounds. Requesters learn to submit earlier with less information, which produces more rejections, which invites more steps in a well-meaning attempt to fix the problem. Before adding an approver, ask:
- Does this approver ever change the outcome? If the answer is no, the step is ceremony.
- Is the step there to enforce policy or to catch mistakes? Policy steps need evidence, not opinions.
- Do the approvers need to see each other's decisions? If not, parallel routing removes the wait.
- Does the step apply to every request, or only above a threshold? If only sometimes, it is a conditional step and should be modelled as one.
How do requests move between states?
A state machine is a model where a record sits in exactly one status at a time and only defined transitions can change that status. Name the states, then give every transition a trigger and a guard.
A trigger is the event that starts a transition. A guard is the condition that must be true for it to complete. A short state list, something like draft, submitted, in review, approved, rejected, cancelled and expired, is easier to reason about than a status field holding thirty values. Two rules keep the model honest: every state must be reachable, and every state must have a way out. Requests stuck in a status that no code path can move are the most common defect in homegrown approval systems, and they usually surface months later during a reconciliation.
What happens when an approver does not respond?
Silence is the failure mode that breaks most approval workflows: the request sits with someone on leave, the requester assumes it was rejected, and the work restarts from scratch. Reminders, deadlines and delegation rules exist to stop that.
A workable default is a reminder after roughly 24 hours, escalation to the approver's manager at about 48 hours, and a delegation record for planned absences. Automatic approval on timeout is a bad default for anything above a trivial value. If you need it for low-value requests, log it as loudly as a manual approval so nobody mistakes silence for consent. Record approvals made on behalf of someone else as the delegate acting, with the original approver named, because the audit trail question is always about who actually decided.
What should an audit trail capture?
An audit trail is an append-only record of every action on a request: who acted, when, from where, and what changed. Regulators and internal reviewers ask for it, and so does anyone resolving a dispute six months later.
Capture the actor, the role they acted in, a timestamp, the previous and new state, any comment, and the version of the rule set that was in force. That last field matters because rules change, and a decision made in March has to be explainable against March's thresholds. The practical way to get this right is to store the workflow definition as data: states, transitions, roles and thresholds live in tables or configuration files, not in hard-coded branches. A spend limit change then takes minutes instead of a release cycle.
How to sequence the build
- Write the states, transitions, roles and thresholds on one page before any code. If it does not fit on a page, the process is too complicated for a first release.
- Implement the state machine and the audit trail first, because they are the parts hardest to retrofit.
- Add routing and a single approval queue next, so approvers have one place to act rather than an inbox full of links.
- Add notifications and escalation once you can see which steps actually stall.
- Build the requester's status view last, when the underlying states have stopped changing every week.
The order matters. A workflow that routes correctly but keeps no audit trail can still fail an audit, while an audit trail with no routing rules is merely inconvenient. A single approval type typically takes roughly four to eight weeks to build, test and hand over when the surrounding application already exists, and each additional type costs less because the shared components are already in place.
If you are commissioning this work rather than building it in house, the state model, the role structure and the audit trail are the parts worth specifying in detail before anyone writes code, which is the shape of the work we do on custom SaaS platforms.
The rules will change. Finance moves a threshold, a regulation adds a step, two teams merge and their approval matrices have to be reconciled. A workflow built as data survives that. A workflow built as a stack of conditional branches does not.
Frequently asked questions
What is an approval workflow in a business application?
An approval workflow is the rule set that decides who must sign off on a request, in what order, and what happens when a step is not actioned. In a custom application it usually sits on top of a state machine, so each request holds a defined status and only allowed transitions can change it.
How long does it take to build a custom approval workflow?
A single approval type typically takes roughly four to eight weeks to build, test and hand over, assuming the surrounding application already exists. Additional approval types usually take less time because the state model, audit trail and approval queue can be reused.
Should approvals run in sequence or in parallel?
Use sequential routing when each approver needs to see the previous decision, such as a manager followed by a director. Use parallel routing when the approvers are checking different things, such as finance and legal, because it cuts the elapsed time to roughly half.
What happens if an approver never responds?
Set a reminder after roughly 24 hours, escalate to their manager at about 48 hours, and allow delegation for planned absences. Automatic approval on timeout is risky; if you use it, restrict it to low-value requests and record it clearly in the audit trail.