"I need an approval flow" is one of the most common requests in document management projects - and one of the most poorly specified. Approving a small invoice has nothing in common with approving a safety procedure that needs an auditable trail for five years. Below are the seven available models and the criteria for choosing.
1. Native library content approval
A versioning setting: the document stays Pending until someone with permission approves it. No code, no extra licence.
Use when: the rule is simple - one group approves, everyone else reads. Avoid when: you need ordering, deadlines, reminders or recorded justification.
2. Power Automate with a single approval
The Start and wait for an approval action triggers on item creation or change. The approver responds from email, Teams or the approvals app, and the flow writes the outcome back to the document column.
Use when: one approver decides and you want traceability, notification and automatic status updates. This covers 80% of real cases.
3. Parallel approval (everyone must approve)
Several approvers are notified at once and all must respond before the document moves on. Typical for documents needing simultaneous sign-off from Legal, Compliance and a technical area.
Watch out: with no deadline, the flow stalls on the slowest approver. Always combine with time-based escalation (item 7).
4. Parallel approval (first to respond)
Same broadcast, but the first response decides. Ideal for duty queues where any qualified analyst can release the document and the goal is shorter waiting time.
5. Sequential, stage-based approval
Approvals are chained: supervisor, then manager, then director. Each stage starts only when the previous finishes, and a rejection midway ends the process and returns the document to its author.
Use when: hierarchy matters and each approver needs to see the previous decision - typical for normative documents and capital spending.
6. Conditional approval by threshold
The flow reads a column on the document - value, criticality, category - and picks the route dynamically:
- Up to 5,000 - immediate manager only.
- From 5,000 to 50,000 - manager then controlling.
- Above 50,000 - adds the board as a final stage.
Keep the threshold table in a SharePoint list rather than inside the flow. When limits change - and they do - the business edits a row instead of raising a ticket.
7. Automatic escalation by deadline
Not a standalone model but the layer that makes the others reliable. With a wait-until action and a check loop, the flow nudges the approver on D+2, reroutes to a delegate on D+5 and notifies the process owner on D+7.
Without escalation, every approval flow eventually becomes an invisible queue of documents parked with whoever went on holiday.
Comparison
| Model | Complexity | Best fit |
|---|---|---|
| Native approval | Very low | Simple content publishing |
| Single Power Automate | Low | One approver, with traceability |
| Parallel (all) | Medium | Joint sign-off across areas |
| Parallel (first) | Medium | Duty queues and short SLA |
| Sequential | Medium/High | Hierarchy and normative documents |
| Conditional threshold | High | Procurement, contracts, investments |
| Deadline escalation | Complementary | Any flow with an SLA |
Three mistakes that show up in almost every audit
- Approver hard-coded in the flow. The person leaves and the process breaks. Reference a group or an owner column.
- Decisions without justification. Make comments mandatory on rejection - that is what lets you find the bottleneck later.
- No error handling. Configure a run-after action to alert a technical owner; a flow that fails silently is worse than no flow.
The general rule: start with the simplest model that solves the case and only add complexity when a concrete business requirement demands it. Every extra branch is code someone will have to maintain.