Search for approval workflows and the answer is almost always a product. Ten tools, a comparison table, a free trial. Buy the routing and the chasing stops.
Agencies that have bought one know it rarely works out that way. The tool routes the request and sends the reminders. What it does not decide is the harder question underneath: when someone edited the file after the client approved it, does that approval still stand?
This guide answers that. It covers the states an approval moves through, the fields that make an approval verifiable months later, and a rule for what has to go back when the work changes. It ends with a worked example and the parts a system should never be allowed to do.
What is an approval workflow?
An approval workflow is the defined path a piece of work takes from submission to a recorded decision: who reviews it, against which criteria, and what happens on approve, reject or changes requested. The decision binds to one identified version of the work, which is the part most teams leave implicit.
That last clause carries the weight. An approval is not a general statement that the work is good. It is a statement that this version, judged against these criteria, is authorised for this use. Change the version and you have changed the thing that was approved.
Why approvals stall in agencies
Approvals rarely stall because nobody bought software. They stall for three reasons, and all three are design problems.
The first is an unnamed approver. Work sent to a team is work sent to nobody, which is why the agency processes guide insists on exactly one named approver per output. The second is unwritten criteria: reviewers invent a standard each time, so the same deliverable passes on Tuesday and fails on Thursday.
The third is version drift. The approved file and the delivered file are not the same file, and nobody can say when they separated. The first two are widely understood. The third is the one that reaches clients.
The five states an approval moves through
Most approval processes track two states, done and approved, which is why work gets stuck in the space between them. Five states cover what actually happens, and each one names who can move it.
| State | What it means | Who moves it | Where it can go next |
|---|---|---|---|
| Submitted | The work is complete and is asking for a decision | The person who produced it | In review |
| In review | The named approver holds it and the criteria apply | The approver | Approved, changes requested, or rejected |
| Changes requested | Specific written changes are needed before a decision | The approver, then the owner | Back to submitted, as a new version |
| Approved | This exact version is authorised for its stated use | The approver | Superseded, on any later change |
| Superseded | An approved version was replaced by a newer one | Whoever made the change | Needs a new decision |
The fifth state is the one worth adding to whatever you use today. Without it, an approval looks permanently valid, including for a file that has since been edited twice.
What an approval record must contain
An approval is only as good as the record it leaves. Six fields make it verifiable by someone who was not in the room, which is the test that matters when a client asks who signed off on a claim in March.
| Field | Example | Why it is there |
|---|---|---|
| Artifact | Monthly performance report, Client A, October | Identifies what was decided on |
| Version identity | v4, with the date and time it was produced | Binds the decision to exact content |
| Decision | Approved, changes requested, or rejected | The act itself, in fixed vocabulary |
| Approver | One named person, not a team or a channel | Accountability that survives staff changes |
| Criteria applied | The checklist version used for the review | Records what approved meant at the time |
| Scope | Whole document, or the named sections reviewed | Makes partial re-approval possible later |
Scope is the field teams skip and later wish they had. Without it, every change forces a full re-read, because nobody can prove which parts were examined the first time.
What happens when the work changes after approval?
An edit after approval does not automatically void the decision, and it does not automatically preserve it. Classify the change, then apply one rule: if the change could alter the decision a reader would make, it needs a new decision.
The three kinds of change
- Presentation only. A typo in a subheading, a logo swapped for its current version, a chart recoloured to the client's palette. The approval holds. Log the edit against the approved version so the record stays honest.
- In-scope correction. A figure re-pulled from its source and corrected within the criteria already applied, with the conclusion unchanged. The approval holds for everything else; only the corrected element returns to the approver. This is where the scope field earns its place.
- Material change. A new claim, a changed recommendation, a number that changes the story, or anything that alters what the client is being asked to believe. The previous approval is superseded and the work needs a full decision, not an acknowledgement.
Why the boundary is worth writing down
Every agency has an unwritten version of this rule, and it drifts under deadline. Written down, it settles arguments in seconds and gives junior staff permission to escalate without feeling obstructive.
Write it once, per deliverable type. A report and a paid social creative have different thresholds for what counts as material, and pretending otherwise produces either bottlenecks or accidents.
A worked example: the monthly client report
The following example is fictional, including its figures, people and approvals. It demonstrates a method, not a client result.
An account manager submits the October report for Client A as v3 on the fourth working day. The named approver is the account director, with the head of performance as backup. The criteria are the standing report checklist: every figure traced to its source, commentary consistent with the figures, no claim the data does not support.
The director approves v3 on the fifth working day, scope recorded as the whole document. The record now says which version, which criteria, who, and when.
On the sixth working day an analyst notices the paid search conversion figure was pulled before the platform finished attributing, and re-pulls it. The number moves. The report becomes v4.
| What changed in v4 | Class | What has to happen |
|---|---|---|
| A footer date corrected | Presentation only | Approval on v3 carries to v4; the edit is logged |
| Conversion figure re-pulled, conclusion unchanged | In-scope correction | The corrected figure and its sentence go back to the approver, not the whole report |
| Conversion figure re-pulled, and the recommendation changes as a result | Material change | v3 approval is superseded; v4 needs a full decision before it is sent |
Notice what the classification protects. In the third row the report is not merely corrected, it now recommends something different, and the person accountable for that recommendation has not yet seen it.
Routing, backups and the reminder ladder
Routing is the well-covered part of this subject, so it needs only the agency-specific version. Sequential routing suits work where one review depends on another, such as legal after strategy. Parallel routing suits independent checks that would otherwise queue behind each other.
Two additions matter more than the routing model.
- Name a backup approver at the same time as the approver, not when the approver goes on holiday. The backup is a person, with the same criteria and the same authority.
- Define the reminder ladder in advance: a reminder after a stated interval, a second reminder, then escalation to the backup. Escalation is a normal event, not a complaint about a colleague.
Approvers and backups are worth settling during client onboarding, alongside access and tracking, rather than discovered in the first week of delivery.
Where automation belongs, and where it does not
A system can do most of this work. It can assemble the submission, check the mechanical criteria, route to the right person, hold the version identity, chase on schedule, escalate on time and write the record. That is the entire administrative burden of approvals.
What a system cannot do is approve. Approval is an act of authority by a named person who carries the consequence. Anything a system produces on the way to that decision is advisory: a check, a flag, a recommendation, a draft.
Which makes the timeout rule easy. If nobody decides, the work is not approved.
Auto-approval on a timer is not hypothetical. It ships as a configurable option in mainstream approval tooling: ServiceNow's approval action takes a due date that can automatically approve, reject or cancel when no decision has been made by a given time, and access tools offer the same behaviour as a skipped step. It converts an absence of attention into recorded authority. Escalate to the backup instead, and let the work wait if it must.
This is the same boundary the three control levels draw across every automated workflow: work that runs automatically, work where humans see only the exceptions, and work that requires approval. Approval-required steps are where a human decision is the point, not an overhead to be optimised away.
Running this in the stack you already have
None of the above requires new software. The six record fields fit a table in the spreadsheet tool your agency already uses. The routing and the reminders fit the chat tool where the work already gets discussed. The artifact keeps its version history where it already lives.
A dedicated tool is a reasonable purchase once the volume justifies it. It is a poor first move, because a tool inherits whatever design you give it. Buying one before the states, criteria and re-approval rule exist buys faster movement through an undefined process.
The thing being approved deserves the same discipline. A client brief that names decisions and owners is reviewable in minutes; a brief that leaves them implicit produces approvals that mean nothing later.
How to tell whether the design is working
Three counts are enough, and none of them is the number of approvals completed. That one only measures traffic.
- Time in review: submission to decision, per deliverable type. This is the number people assume is the problem, and often is not.
- Material-change rate: how often approved work later needs a full new decision. This is the honest measure of whether the criteria describe what actually matters.
- Escalation rate: how often the backup approver is used. Rising escalations are usually a capacity signal, not a discipline problem.
The second count is the one that repays attention. A high material-change rate is rarely a careless approver. It usually means the criteria were written for a document that no longer resembles the work, so reviewers pass things the criteria never asked about.
Fix the criteria before adding a review step. Adding approvers to a process with vague criteria produces slower work at the same quality.
What to remember
- An approval binds to one identified version, judged against stated criteria. Anything looser cannot be verified afterwards.
- Five states beat two. Superseded is the one most teams are missing, and it is the one that catches edited files.
- Record six fields: artifact, version identity, decision, approver, criteria applied and scope. Scope is what makes partial re-approval possible.
- Classify every post-approval change as presentation, in-scope correction or material, and apply one rule: if it could alter the decision a reader would make, it needs a new decision.
- A system prepares, routes, chases and records. A named person approves. Silence is not approval.
If you want to see where this would sit in your own delivery, and which recurring deliverable is worth designing first, book a free mapping call. Thirty minutes, no commitment.
