How to create a document approval workflow

How to build a document approval workflow that routes before it signs: classify the change, let the document type set its reviewers, and give an editorial revision a route that skips review.

A document approval workflow is a routing decision before it is a signature chain: the document's type and the significance of the change together determine which reviews and approvals apply.

The short version

  • Classify the document first. Its type sets the mandatory reviewers, not the workflow designer.
  • An editorial revision that changes no meaning wants a log entry, not a review round.
  • Review converges on the author; a countersigning approval has to follow the approval it countersigns.
  • Name the trigger for a second approver rather than naming the second approver.
  • Publication is not one state: a logged editorial update and a release carrying training differ.

Most documents do not need most reviewers

Every document approval workflow contains a classification step, and most of them never draw it. Somebody still decides that this revision needs three reviewers and that one needs none, from habit, from who is available, from how much trouble the last version caused. Drawn, that decision is a rule with a record behind it. Undrawn, it is a run of individual judgements that cannot be shown to have been applied the same way twice, and consistency is the only property of a routing rule anyone can check.

A useful routing question is one the person submitting can answer in a minute, without reading the document's substance: what kind of document this is, whether it is regulated, and whether the change alters what somebody has to do. A question that needs the reading it exists to avoid has already spent the saving it was added for. That is the test the classification has to pass, and it is why these questions are about the document and never about which reviewer happens to be free.

The example below is a decision tree rather than a chain, and the routing is settled before anybody reads the document. "Editorial or substantive change?" diverts a revision out of review altogether, and "Can the author resolve now?" sends an unresolved comment back to "Collect reviewer comments" for a further round: a return a chain diagram has no way to draw, which is why a chain always looks faster on paper than the process it describes.

Eight decisions, one loop

A document approval decision tree whose first three questions decide how much of the rest of it applies at all.

  1. Classify before you route

    An editorial revision leaves the workflow before anybody reads it. "New document or revision?" hands a revision to "Editorial or substantive change?", whose "Editorial" branch reaches "Log the editorial correction": an exit two questions in, with the workflow deciding what it owes the document.

  2. The review loop, drawn honestly

    Classification gates the review: "Regulated document type?" adds quality and regulatory reviewers where a management system or a licence applies. Comments converge on one step, and "All review comments resolved?" hands the open ones to "Can the author resolve now?", whose "Yes" goes round again.

  3. Approval, then the second name

    Approval enters as two rows, one reading and one deciding: "Approver reviews the final draft" precedes "Approve for release?", and at this cut only its "Approved" exit has anywhere to go, reaching "Second approver required?", where "Obtain the second approval" adds a countersignature.

  4. Publication has more than one ending

    "Read-and-understood required?" decides whether release carries a training obligation, and the finished tree offers three published states alongside "Returned to the author for rework" and "Rejected and closed": five outcomes the workflow can genuinely produce.

How it works

  1. Build the routing table before the diagram

    One row per document type, and two columns people will argue about: the reviewers that type makes mandatory, and the level of authority that may release it. Settle them there, where an argument costs an afternoon rather than a revision. The diagram that follows renders the table, so a type nobody agreed on becomes a route nobody follows.

  2. Define editorial against substantive in writing

    Editorial means a reader would do nothing differently: typography, layout, a renamed department, a corrected cross-reference. Everything else is substantive. Name who arbitrates a disputed classification, because the borderline cases (a changed tolerance figure, a reordered step list) are where the definition is worth having.

  3. Make the routing questions the first rows

    Type the classification questions into the top rows of the sheet and mark each one Decision in the Shape column. Because Line to holds row numbers, a route that skips the whole review block is just a number that jumps past it: the editorial exit is one figure, not a redrawn diagram.

  4. Collapse review into one row, then order the signatures

    Reviewers working simultaneously are one row: their comments arrive in parallel and converge on the author. Sequence approvals only where a later signature countersigns an earlier one, as "Obtain the second approval" does; the rest is habit rendered as a diagram. Branch words go in Line text against the numbers they carry, in that order.

  5. Give every outcome its own terminator

    Set Shape to Success where the document is published, Reject where it is refused, End where it goes back to the author. Three published states are not redundancy: published after full approval, published with training assigned, and a logged editorial update leave genuinely different obligations behind them.

  6. Replay three logged revisions through it

    Take the last three entries from the document control log and classify each using only the first three questions. If all three land on the same route, the classification is doing no work yet: either the definitions are drawn too broadly, or those three revisions really were alike. Widen the sample until one of them diverges.

Mistakes to avoid

  • Routing that lives in one person's head

    A fixed chain at least applies where everyone can see it. A routing rule held informally is interpreted document by document, and the interpretations drift one way: the changes with most at stake take the shortest route.

  • Editing after the approval

    An approver signs a draft; a formatting pass, a late correction or a merged comment then lands before publication. If the released file is not the file that was approved, the signature belongs to a version nobody holds.

  • Asking for the second name too late

    "Second approver required?" sits after "Approve for release?", so whether a countersignature is needed is settled once the first approver has committed. Which types need two names is knowable at classification: ask it there.

  • Acknowledgement for everyone or nobody

    Both defaults fail. Acknowledgement demanded for every formatting tweak trains people to click through it, and never demanded means no evidence that anyone works to the current revision of a changed procedure.

Related QueryChart feature

Explore version history and change tracking

Build your own document approval flow

Open the decision tree as your own chart and set the questions that decide which reviews and approvals your documents actually need.

Build your own document approval flow

Related guides

Frequently asked questions

Who should approve a document, and who should only review it?

The approver is the process owner for that document, or whoever holds the delegated authority for its type: a single named person, never a role inbox. Reviewers are not chosen document by document either: the list belongs to the document type, which is what "Regulated document type?" settles in the example by adding quality and regulatory names to a route that would otherwise carry neither. Argue about the type once and you have decided every future revision of it.

Does every document revision need a full approval round?

No, and treating it that way is why review cycles run for weeks. A revision that changes no meaning (formatting, a renamed department, a corrected reference) needs a recorded editorial update, not a fresh round of signatures. Anything that changes what somebody must do takes the full route, including the reviewers its document type makes mandatory. What matters is that the test exists before the revision arrives, and that the author is not the only person applying it.

How many rounds of review should a document need?

One, and a second only where the first round found something substantive. What the workflow has to state is what happens when the second round does not close either, which is the job of "Can the author resolve now?": its "Yes" sends the comments round again, its "No" ends at "Returned to the author for rework": a decision to stop reviewing a draft that was not ready rather than to keep circulating it. Rounds without a limit produce four reviewers' worth of comments and no owner.

What is a read-and-understood record for?

It is the evidence that the people doing the work know about the change, a separate question from whether the document was approved. Demand it where the revision alters what somebody must actually do in a regulated, safety-critical or customer-facing step, and it means something; demand it for every wording change and it is a click. Auditors look at the gap between a document's effective date and its acknowledgements, because that interval is when people were working to the old revision.

The template behind this guide

Document approval workflow decision tree template — A document approval workflow decision tree: editorial or substantive change, mandatory reviewers by document type, second approver, and training on release.

Browse all Governance, Audit & Compliance Guides

Document approval workflow decision tree: Intake → Classification → Review → Approval → Release
How to create a document approval workflow