An approval workflow is a defined sequence of reviews and decisions that a request must pass before it becomes an official action—purchase order release, discount grant, refund, access grant, content publish, or invoice payment. Software enforces who must approve, in what order, under which thresholds, and what happens on rejection or a request for changes.
Without a workflow, approvals hide in chat threads and email forwards. With a workflow, status, history, and accountability stay visible—and the next system step (PO issue, payment queue, CRM update) only runs after a clear decision.
Concrete examples
Purchase order (PO)
A buyer submits a PO request with supplier, lines, and budget code. Under a threshold, the department manager alone can approve. Above it, procurement and finance review in sequence. On approval, the ERP creates or releases the PO; on rejection, the buyer sees reasons and can revise.
Discount or credit note
A salesperson requests a non-standard discount. Rules route by discount percentage and customer tier: sales lead first, then finance for deep discounts. The CRM or quoting tool applies the price only after the final approve—so “I already promised the customer” cannot bypass policy.
Supplier invoice payment
After capture and validation in invoice automation, invoices below a limit auto-approve for payment queue; larger amounts or mismatched PO lines require cost-centre owner then finance. The ledger post or payment batch waits on the decision trail.
Common workflow types
- Single approver — one manager signs off
- Sequential — department, then finance, then a director
- Parallel — several reviewers; proceed when all (or a defined quorum) approve
- Threshold-based — auto-approve below an amount; escalate above it
- Role- or attribute-based — route by cost centre, branch, category, or risk flag
- Conditional / branching — different paths for capital vs operational spend, or for new vs existing suppliers
Many real programmes combine these: threshold gates pick a path, then sequential or parallel steps run inside that path.
Approval workflow lifecycle
- Requester submits with evidence and context
- Rules select path and approvers
- Approvers decide approve, reject, or request changes
- System records the decision trail
- Downstream action executes or stops
Implementation considerations
- Short paths — every extra approver adds latency and rubber stamps. Encode only controls you will enforce.
- Delegation and out-of-office — acting approvers prevent freezes and informal email bypass.
- Segregation of duties — requesters should not approve their own high-value items; encode it, do not rely on politeness.
- Evidence and comments — require rejection reasons and attachments for policy exceptions.
- Mobile-friendly actions — managers often decide from messaging or a phone; one-tap approve/reject with context beats desktop-only portals.
- System handoff — outcomes must update ERP, accounting, CRM, or payment queues via workflow automation, not a manual second entry.
- SLAs and escalation — overdue steps should remind, then escalate to an alternate role.
- UAT with real examples — test edge cases (exact threshold, multi-currency, substitute approver) before go-live; see what is UAT.
Design tips that keep work moving
Separate data-quality exceptions from policy approvals. If the invoice total does not match the PO, fix that in an exception queue before asking a director whether the spend is allowed. Keep notifications actionable: what it is, how much, why it needs them, and a link to decide.
Common mistakes
- Approving everything, so every step becomes a stamp and real risk is ignored
- Building deep hierarchies that nobody can complete during leave periods
- Hiding rules in undocumented chat conventions instead of system configuration
- Letting requesters edit amounts after approval without re-routing
- No audit export when auditors ask who approved a payment three months ago
- Coupling approval UI so tightly to one channel that WhatsApp or email “side doors” become the real process
Measuring whether the workflow helps
Track average time in each step, percentage auto-approved by threshold, escalation rate, and rework after “request changes.” If almost everything auto-approves and exceptions never fire, thresholds may be too loose—or volume never hit the risky cases you designed for.
FAQ
Should everything require approval?
No. Over-approval creates rubber stamps. Use thresholds and risk-based paths so attention stays where it matters.
What is the difference between validation and approval?
Validation checks whether data is complete and consistent (supplier exists, totals add up). Approval is a policy decision (is this spend allowed?). Run validation first.
Can approvals run in parallel?
Yes—for example legal and finance reviewing a contract pack. Define whether you need all approvals or any one of a set, and what happens if they disagree.
How do discounts and invoices share one engine?
Share the engine (roles, SLAs, audit); keep separate rule sets and forms per request type so PO, discount, and invoice paths do not confuse each other.
What if the only approver is on leave?
Use delegation or an acting role before go-live. Without it, people will approve by email and the control collapses.
Related concepts
Invoice path after capture: how invoice automation works. Broader automation: what is workflow automation and business process automation.