How to create an approval workflow
How to design an approval workflow: decide what each gate is really deciding, set thresholds from your delegation of authority, route rejections somewhere, and record who approved what.
A worked example, stage by stage
Screen before you spend review effort
A business case and a proceed decision that can stop the process on the first step. The cheapest gate goes first: reviewing a supplier nobody has agreed to pursue is the most common waste in approval workflows.
Chasing is part of the workflow
The questionnaire gate loops back for missing evidence rather than failing. Most real approval processes spend more elapsed time chasing incomplete submissions than deciding, and drawing that loop is how it becomes measurable.
Depth of review follows risk
A risk-tier decision routes high-risk suppliers to an on-site audit with its own corrective-action loop, while lower tiers skip straight ahead. Uniform review depth is the most common design error: it over-reviews the trivial and under-reviews the dangerous.
Three outcomes, not two
The approval authority can approve, approve with conditions, or reject — and conditional approval records its conditions before listing. Binary gates force approvers to choose between blocking legitimate work and waving through something imperfect.
How it works
Write down what each gate is deciding
One sentence per approval: what question is this person answering, and on what evidence? Gates that cannot be stated this way are usually there for visibility rather than decision, and visibility is better served by a notification that does not hold the work up.
Take the thresholds from your delegation of authority
Value bands, risk tiers and materiality limits belong to the delegation schedule, not to the workflow designer. Put the figures and the currency on the decision itself so the routing is auditable, and set them high enough that the extra gate triggers rarely.
Give each gate exactly one accountable approver
Others may be consulted; one person answers for the decision. Committees can approve, but then the committee is the approver and its quorum and chair need naming. Two independent approvers at the same level is the shape that produces neither reviewing carefully.
Route every refusal
Draw where a rejected item goes: back for amendment with the reason recorded, up for escalation, or to an explicit closed state. Workflows that leave rejection undrawn produce items that are neither live nor closed, sitting in a state nobody is chasing.
Make the depth of review follow the risk
Add a routing decision before the expensive reviews, as the example does with its risk tier. Applying full diligence to everything means either the process is too slow or the diligence is not real, and it is usually both.
Capture the evidence of approval
Each approval needs an approver, a timestamp and the version it applied to. In QueryChart the chart itself carries an approval workflow and an immutable history, so "who approved the version in force in March" has an answer without anyone searching an inbox.
Frequently asked questions
How many approval levels should a workflow have?
As few as make real decisions — usually one, with a second above a threshold taken from your delegation of authority. Each additional gate adds queue time and dilutes accountability: approvers who are one of five review less carefully, not more, so a five-gate workflow can be a weaker control than a two-gate one while costing considerably more. If a gate has never rejected anything, that is the evidence it should be a notification.
What is the difference between an approval and a review?
An approval is a decision that can block the work and carries accountability for the outcome; a review is an examination that produces comments. Conflating them is a common design fault: reviewers get given a veto they were not meant to have, or approvers are treated as reviewers and their sign-off means nothing. Draw reviews as steps and approvals as decisions, and the distinction becomes structural rather than a matter of convention.
Should approvals be parallel or sequential?
Sequential when a later approver relies on an earlier one's decision, parallel when they are assessing independent things. Most workflows are drawn sequentially out of habit, adding days for no analytical reason — legal reviewing contract terms and finance assessing credit do not need each other's outcome. Parallel gates are harder to represent in some ticketing tools, which is a tooling constraint worth naming rather than encoding as process design.
How do I record approvals for an audit?
Capture the approver, the timestamp, and the exact version approved — the last is the part usually missing. An approval that cannot be tied to a specific revision proves only that someone approved something at some point. QueryChart records approvals against a chart revision with an immutable history, so the question an auditor actually asks — which version was in force, and who signed it — is answerable directly.