Document approval workflow: Drive-native routing, version control and audit trail
This page covers how document routing works stage by stage, how automatic locking keeps a document stable while approval is open, how approval binds to a revision rather than to a filename, and the edge cases that break most implementations — starting with the most common one, someone editing a document that is already in the approval chain.
What a document approval workflow actually controls
Reviewing a document is easy. Knowing afterwards which version was approved is the hard part. A document approval workflow exists to answer three questions that a shared link and a thread of comments cannot: which revision did each approver agree to, who was allowed to change it while they were deciding, and what the document looked like at the moment of sign-off.
That makes three mechanics load-bearing — routing, which decides who sees the document and in what order; locking, which controls who can edit it while a decision is pending; and versioning, which binds each approval to a specific revision rather than to a filename.
A document approval process that cannot tell you which revision was approved has not recorded an approval. It has recorded an opinion about a document that may since have changed.
System, software, solution
These terms are used loosely and often interchangeably. The distinctions that matter in practice are as follows.
Document approval workflow
The defined process itself: the stages, the order, the approvers, and the rules for locking and versioning.
Glossary: approval workflowDocument approval workflow system
The process as implemented and running — stages configured, approvers resolved, state tracked, decisions logged.
Document approval software
The product used to build and run that system. Some are document-first, some are workflow-first; the difference shows in how they handle locking and versions.
Document routing workflow solution
The delivery of the routing layer specifically — getting the right document to the right reviewer in the right order, with state carried between stages.
Glossary: approval routingApproval chain
The ordered set of stages a given document must clear, from submission to final outcome.
Glossary: approval chainAudit trail
The record of every stage: actor, timestamp, decision, and the revision the decision applied to.
How document routing works, stage by stage
Routing is the part most teams already recognise, because it is the part email approximates badly. A routing workflow solution replaces "forwarded to Legal, waiting to hear back" with a stage that has a known owner, a known state, and a known deadline. This example is a policy document with two sequential reviewers.
The owner submits the document, and it locks
Submission is the event that starts the chain, pins the current revision, and downgrades edit access. Everything after this point is measured against the revision captured here, which is why the lock and the submission have to be the same action rather than two steps someone can perform out of order.
Legal reviews with comment access only
The reviewer can annotate but cannot alter the text they are approving. Comments are useful and expected; silent edits are what destroy the record. If Legal requires changes, the chain pauses rather than advancing, and the document returns to the owner unlocked.
Department head signs off on a known revision
The final approver sees a document that has already cleared Legal and has not changed since. On approval the document is published, exported, or sent for signature, and the audit trail closes with the revision identifier attached.
Automatic locking while approval is in progress
This is the mechanic that separates a document approval workflow from a document review. If a document can change while approvers are deciding, then an approval means nothing more precise than "this looked acceptable at some point." Locking removes that ambiguity, and it needs to happen automatically — a lock that depends on someone remembering to apply it is a lock that is missing exactly when it matters.
Lock automatically
The moment the document enters the chain, edit access is withdrawn and the current revision is pinned. Editors become commenters, so review can continue without the text moving underneath it. The owner keeps visibility of the document and its stage, but not the ability to change it.
- Editors downgraded to comment access
- Current revision pinned as the one under review
- Lock applied by the workflow, not by a person
Unlock for the owner
A rejection is not the end of the document, it is a request for a new revision. Edit access returns to the owner alone so they can act on the feedback, while reviewers stay read-only. The chain pauses rather than closing, and resubmission pins a fresh revision and re-locks.
- Edit access returns to the owner only
- Reviewers remain read-only during revision
- Resubmission pins a new revision and re-locks
Lock and record
The approved revision is the artefact worth protecting. Access settles at read-only for everyone except a named owner, the revision identifier is written to the audit trail, and any onward action — publish, export, send for signature — runs against that specific revision.
- Approved revision recorded by identifier
- Read-only for all but a named owner
- Onward actions bound to the approved revision
Two details are worth settling before you configure any of this. Decide whether the lock removes edit access or merely warns — a warning is easier to ship and provides no guarantee. And decide who can override a lock, because someone will need to, and an override that is not logged is a hole in the audit trail rather than a convenience.
Approval attaches to a revision, not to a file
A filename is not a version. Two people can look at the same document a week apart and see different text, which is why an approval recorded against a document is close to worthless while an approval recorded against a revision is evidence.
What the workflow needs to capture
At minimum, the revision identifier at the moment of submission, the identifier at the moment of each decision, and whether those two differ. If they differ, something changed mid-review and the approval needs to be reconsidered rather than recorded. Google Drive keeps a full revision history for Docs, Sheets and Slides, so this identifier already exists — the workflow's job is to capture it at the right moments and store it alongside the decision.
Named versions at approval
Drive lets a revision be named, which turns an arbitrary point in history into a retrievable one. Naming the approved revision at sign-off — with the approval date and chain identifier — means the approved text can be recovered years later even after the live document has moved on through further rounds.
Where teams get caught out
Exporting to PDF at approval feels like version control and is not. A PDF proves what the text said; it does not prove that the live document still matches, and it creates a second artefact that can drift from the first. Export if the process needs a fixed deliverable, but keep the revision identifier as the record of what was approved.
The six cases that break document approvals
Every tool handles the happy path. These are the situations that decide whether the audit trail is defensible, and they are worth settling explicitly before anything is configured.
Someone edits a document that is already in the approval chain
Prevent it with an automatic lock at submission; if an edit still lands, invalidate the approvals given against the earlier revision and restart the affected stages. This is the most common failure in document approval, and it is usually not malicious — a co-owner with edit rights opens the file and fixes a typo, unaware that two approvals already exist against the previous text. Detection is the fallback, not the plan: compare the revision identifier at each decision against the one pinned at submission, and treat any difference as a material change. Because the correct response depends on where in the approval chain the edit occurred, decide in advance whether an edit rolls back one stage or all of them.
An approver edits instead of commenting
Give reviewers comment access rather than edit access for the duration of the stage. An approver who rewrites a clause and then approves it has approved their own work, which defeats the point of the review and leaves an audit trail that cannot distinguish reviewer from author. Comment access preserves the useful part of their input while keeping the text stable, and it makes the resulting record legible: comments are attributable, silent edits are not.
The document is rejected and the owner cannot edit it
Unlock for the owner automatically when changes are requested, and only for the owner. A lock that persists through rejection turns a routine revision into a support request, and teams respond by copying the document to a new file — which is how a single approved document becomes three near-identical ones. Restoring edit access to the owner alone keeps the revision history in one place while preventing reviewers from editing during the rework.
Two approval chains run on the same document
Detect an open chain at submission and refuse to start a second one on the same document. Parallel chains on one file produce contradictory lock states and two audit trails that each look complete. This happens most often when a document is used in two processes — a contract in both a legal review and a procurement approval. If both genuinely need to run, model it as one chain with two parallel stages rather than two independent chains.
An approver is unavailable and the document sits locked
Configure a delegate, a timeout, and an escalation target on every stage. The cost of a stalled stage is higher for documents than for most approvals, because the document is locked while it waits — the owner cannot make progress either. Delegated approvals should record both the delegate and the original approver. Avoid auto-approval on timeout; auto-escalation moves the document without removing the control the stage was added to provide.
Someone asks, two years later, what was approved
Log actor, timestamp, decision, and the revision identifier at each stage, and name the approved revision at sign-off. The revision identifier is the field most often missing, and without it the trail records that somebody approved something. Overrides, delegated decisions and timeout escalations all need to appear as events in their own right — an audit trail with silent gaps is harder to defend than one that shows an override and who made it.
Document approval software compared
The category mixes three quite different kinds of product, and the distinction matters more than any feature list. Document-first tools centre on the document and its signature lifecycle. Workflow-first tools centre on the process and treat the document as a payload. Work management platforms add approval as a step inside a broader project tool. Which one fits depends on whether your constraint is the document, the routing, or the surrounding work.
| Platform | Category | Typically chosen for |
|---|---|---|
| Notion | Workspace & docs | Teams whose documents already live in Notion and who want lightweight review inside the same workspace. |
| DocuSign | Document-first, e-signature | Processes where the signature is the outcome and the agreement lifecycle is the main focus. |
| Zenphi | Workflow-first, Google-native | Teams on Google Workspace who need approvals to run natively on Google Docs — routing, automatic locking and revision capture against the live document. SharePoint, Word and OneDrive actions are first-class too, and signature tools including DocuSign and Adobe Sign integrate directly. |
| PandaDoc | Document-first, e-signature | Proposal and quote workflows where document generation and signing sit together. |
| SharePoint | Document management | Microsoft-centred organisations using libraries, check-in/check-out and Power Automate for routing. |
| Kissflow | Workflow-first | Business process automation across many approval types, with documents as one case among several. |
| Wrike | Work management | Teams wanting document review and proofing inside the same tool they use for project delivery. |
| n8n | Workflow automation, technical | Engineering-led teams comfortable building and self-hosting their own routing logic. |
| Ziflow | Creative proofing | Marketing and creative review, where annotation on visual assets is the core need. |
| Pipefy | Workflow-first | Process owners building request-and-approval pipes without engineering support. |
| ClickUp | Work management | Teams consolidating tasks, docs and approvals into a single project platform. |
| Workato | Integration platform | Enterprise integration programmes routing approvals across many connected systems. |
One practical filter cuts this list quickly: ask where the document is going to live. If the answer is Google Drive, a tool that treats Docs as an attachment will lose the revision history that makes the audit trail worth keeping. If the answer is SharePoint, the same logic applies in reverse. The tools worth shortlisting are the ones that operate on the document in place.
Where hand-built document review comes apart
Document approval usually starts as a folder, a naming convention and a habit of emailing the link. It holds until two people need to approve the same document, or until someone asks which version went out.
Teams graduating from brittle scripts recognise all three of these. None of them announce themselves — each surfaces as a document nobody can vouch for.
Permissions set by hand
Someone remembers to switch editors to commenters, or does not. The lock exists as a convention rather than a rule, so it is missing precisely on the documents that attracted a late edit.
Copies instead of revisions
A locked document gets duplicated so work can continue, and the approved text and the working text separate. Two files now look current, and the revision history of each tells only half the story.
Approval lives in an inbox
The decision is a reply in a thread, detached from any revision identifier. It proves someone said yes; it cannot establish what they were looking at when they said it.
Native depth in Google Workspace, first-class actions for Microsoft 365
Most document workflow platforms reach Google Workspace and Microsoft 365 through generic connectors, which means the document is treated as a file to be fetched and pushed back. That loses the two things a document approval workflow depends on: the revision history, and the ability to change access on the live document.
We build Zenphi natively for Google Workspace, so approvals operate on the Google Doc itself — locking by adjusting access, pinning and naming revisions in Drive's own history, and resolving approvers from the Google Directory. SharePoint, Word and OneDrive actions are first-class rather than bolted on, and signature tools including DocuSign and Adobe Sign integrate directly, so a chain can end in a signature without leaving the workflow.
Google Docs
Approvals run on the live document, with access changes and revision naming applied in place.
Drive
File events start chains, and Drive's revision history is the source of the approved version.
SharePoint, Word, OneDrive
First-class actions for Microsoft-side documents, not generic file passthrough.
Signature tools
DocuSign, Adobe Sign and others connect directly, so the chain can end in an executed document.
Document approvals by process
The locking and versioning mechanics above are the same everywhere. What changes is who approves and what the chain ends in.
Multi-level approval workflow
Sequential, parallel and conditional routing in depth, including thresholds and delegation. The routing layer under any document chain.
Read more →Content approval workflow
Parallel review by legal, brand and subject experts, then a single publish approval. Round-trip revisions are the norm.
Read more →Invoice approval workflow
Amount-based routing with a three-way match before the finance stage. Exception handling matters more than chain depth.
Read more →Purchase order approval workflow
Threshold bands mapping directly to approval depth, where delegation keeps procurement from waiting on one calendar.
Read more →Google Forms approval workflow
Form submissions as the entry point to a chain, with form fields becoming the data conditional rules read.
Read more →Approval workflow software
The category overview: evaluation criteria, routing mechanics and how approval tools differ from each other.
Read more →Document approval workflows — common questions
Decide your locking rules before you build the chain
Locking, versioning and the edge cases above are the decisions worth settling first — they are much harder to retrofit than an extra approval stage. Our docs cover how each maps to a Zenphi flow, and the community is a good place to compare notes with teams running document chains on Google Workspace.