The problem is rarely a missing approval
People usually come to us with the opposite of «we have no approval process»: they have one, but a request takes a week. Every participant was added «just in case», and the document passes through seven people, six of whom simply click Approve without reading.
A chain like that creates the appearance of control, not control itself. When a signature means nothing, nobody reads what they are signing.
Start with «what changes if they say no»
This is the main filter. Before adding someone to the chain, ask: if they reject it — what happens?
- There is an answer — the request goes back for rework, the amount gets cut, the supplier is replaced. That person belongs in the chain.
- There is no answer — «they should be aware». That is not approval, that is a notification. Such a person does not need an Approve button — they need a subscription to events.
In BPM these are different things: an approver blocks the request from moving, a subscriber simply gets notified. Mixing them up is the most common mistake.
Three or four steps is almost always enough
In practice a working chain looks like this:
Requester → Head of department → Finance → Director
And the last step is not always on — it is triggered by a condition, for example only for requests above a certain amount. In BPM this is expressed as a rule: request type, amount, priority.
If you end up with six or more steps, some of them are almost certainly subscribers rather than approvers.
When parallel beats sequential
Sequential mode is for cases where the next person's opinion depends on the previous one: finance reviews the request only after the department head has trimmed the scope.
Parallel mode is for independent reviewers. Legal checks the contract, security checks the counterparty. There is no reason for them to wait on each other.
BPM has two parallel modes, and the difference matters:
- All (PARALLEL_ALL) — every participant must approve. Right for legal and security: you cannot skip either.
- Any (PARALLEL_ANY) — one approval is enough. Right for interchangeable roles: three senior specialists in a department, and whoever is free can close the request.
The second mode cuts a lot of the delay caused by holidays and business trips.
What to do about stuck requests
Even a well-built chain stalls when someone is away or simply forgets. Three things help:
- Visibility. The request register shows immediately who the document is sitting with and how long it has been there. Nobody has to make a phone call to find out.
- Deadlines. Requests carry a due date and overdue ones are highlighted. This works better than reminders because everyone sees it, not just the assignee.
- Return instead of reject. If something is missing, the request goes back to the requester with a comment rather than being rejected. The chain does not restart from zero.
A rule instead of manual assembly
The core idea: a human should not assemble the chain for every request. They will make a mistake, forget a participant, or add one too many.
Instead you describe the rule once — «material purchases above 50M go through finance and the director» — and from then on the system picks the chain itself. You can have several rules; they are evaluated by priority.
Approval then stops depending on who created the request and how well they remember the policy.
Want to see how your rules would map into the system? Get in touch — we will build your chain during the demo.