Document approval workflows: how to design tiered approvals by document type and value

Slow approvals are rarely caused by managers who refuse to approve. The more common cause is an unclear route: the document waits on the desk of someone on leave, the requester does not know who comes next, and nobody knows when a request counts as late. This guide covers how to design an approval workflow so that every document has a clear route, whether you run it on paper or in an application.

Start with who approves what

The first step is to list the document types that are submitted often, then decide two things for each: how large its risk or value is, and who has authority over the decision. Most companies end up with three or four tiers. Routine low-value requests need only the direct manager, mid-value documents go up to the head of division and finance, and high-value or legally significant documents need the directors.

The value thresholds belong in an authority policy that the company holds, not in a decision made each time by whoever happens to be handling the document. The figures in this guide's examples are illustrations only, and you should replace them with the limits that apply in your company.

Route by position, not by person

Write the route with positions, such as "Head of Procurement" and "Finance Manager", and not with personal names. People change divisions, resign or go on leave, while positions remain. If a route uses names, every transfer forces someone to update all the routes, and one is usually missed, so documents end up with someone who no longer holds the role.

There is a sensible exception. For a decision that really depends on one person's expertise, such as a particular lawyer reviewing a special contract, naming the person is more accurate. Keep the two kinds clearly apart so that anyone reading the route can tell which steps are position-based and which are person-based.

Sequential or parallel

Sequential steps fit when one person's decision affects the next. For example, the Head of Procurement checks completeness first, and finance then assesses the budget. Parallel steps fit when several parties assess different things independently, such as legal and finance reading the same contract draft at the same time.

For a parallel step, decide the completion rule up front. There are two common options: the first decision to arrive is enough, or everyone in the step must decide. The first suits a group whose members can stand in for each other, and the second suits approvals where each party has its own interest. Do not make everything parallel just for speed, because an approval that is too loose produces corrections at the final stage.

Delegation, deadlines and escalation

These three keep the route moving when people are unavailable.

• Delegation. The approver names a substitute for a set period, and the substitute's authority should be limited to the actions that are allowed. The decision record must still show who actually decided, and not only the position being covered.
• Deadlines. Every step needs a time limit, for example two working days for routine requests and five for contracts. Without a limit there is no point at which a request can be called late.
• Escalation. Decide who is contacted when the deadline passes, usually the approver's superior or the process owner. Escalation is not a penalty. It is how a document avoids stopping quietly.

The diagram below shows one tiered route with a delegation branch and an escalation when the deadline passes.

Returning with notes

An approver should have three options: approve, reject or return for revision. The third is often forgotten even though it is needed most, because many documents lack only one attachment or one figure that needs correcting. Require a note on every return and rejection so the requester knows exactly what to fix. Also decide whether a corrected document restarts at the beginning of the route or goes back to the step that returned it. For small changes, going back to that step is usually enough, while a change that touches the value or the core content should restart the route.

Example routes by document type

The table below is only an example. Positions, value limits and the number of tiers must be adapted to your company's authority policy.

The table shows a repeating pattern: the larger the value or impact, the more tiers a document passes through, and parallel steps are used when two functions assess different things.

Testing and maintaining the route

Once a route is designed, try it on real documents before wider use. Watch which step makes documents wait longest, because that is where the deadline or the number of approvers needs another look. Review routes whenever the organisation structure or the authority policy changes. A route change should apply to new documents only, while documents already in progress finish the route they started on.

This guide does not discuss whether a signature is valid. For that, read electronic vs digital signatures.

How Obscura helps

In Obscura your approval policy is stored as a route that runs on its own. Tasks go to a position, so whoever holds it today receives the work, and you can still name a specific person when that matters. Each approver can approve, reject or return a document with a note. Every task has a deadline, overdue tasks follow the escalation path you define, and a substitute can act for a set period and only for the allowed actions, while the record still shows who decided. Stages run in sequence, and within a stage several people can act at once, with either the first decision or everyone's decision completing it. Conditional branching is not part of the current model, so tiers by value are built as separate saved routes, and you pick the right one for each document. The full description is on the approvals and e-signatures page, and the decision history stays with the document as described on the document control page.