Page approval workflows in Confluence, without over-engineering them
"We need an approval workflow for Confluence" usually arrives as a single sentence covering several different requirements. Before adding tooling, it is worth separating them, because native Confluence already covers some, and the ones it does not cover are narrower than the original sentence suggested.
Four requirements hiding in one sentence
Most teams asking for approvals want some subset of:
- A record that a named person accepted the content, retrievable later.
- A way to ask a specific person for that acceptance, and to know it is pending.
- Protection against the content changing after acceptance.
- A signal that acceptance is no longer current once the content does change.
These have very different costs. The first two are largely solved natively. The third is partly solved. The fourth is where teams usually end up needing help.
What native Confluence covers well
Asking, and tracking that you asked. Inline and page comments with an @mention notify the reviewer and leave a durable trail. Action items with an assignee give you a checkbox that is visibly open or closed. For a team of any size below a few dozen, this is genuinely sufficient for requirement 2, and adding software to it is usually a downgrade in flexibility.
Recording the decision. A comment saying "approved" from a named account, with a timestamp, is a real record. It is discoverable in the page, it survives, and it requires no configuration.
Preventing change. Page restrictions limit who can edit. Applied after review, they cover requirement 3 for the cases where locking is acceptable. (Worth knowing: restrictions cascade to child pages, and administrators can still edit — see how to lock a Confluence page after approval.)
Noticing change. Watch a page and you are notified when it is edited. Page history shows exactly what changed and who did it.
If your requirement is "some documents should be reviewed and then left alone", you can do all of this today with no apps at all. A convention — review in comments, restrict on completion — is a legitimate answer, and it is one that never breaks, never bills you and never needs a migration.
Where it stops
The gap is requirement 4, and it is structural rather than cosmetic.
A comment saying "approved" is attached to *the page*. Confluence versions the page underneath it. When someone saves an edit, the comment does not change, does not move and does not acquire an asterisk. The record and the content have decoupled, and nothing in the product notices.
You can compensate manually. Watching the page tells the reviewer something changed. Page history shows what. But this puts the burden on a human to notice a notification, understand that it invalidates an earlier approval, and act. Across a handful of pages, people manage. Across a few hundred, they do not — and the failure is silent, which is the worst property a compliance mechanism can have.
The second gap is aggregate visibility. Native tools answer "is this page approved?" one page at a time, by reading it. They do not answer "which of our 200 reviewed pages have been edited since sign-off?" That question is the one an auditor asks, and answering it by hand does not scale.
A proportionate approach
Match the mechanism to the actual risk:
Low stakes — most internal documentation. Comments and mentions. Do not add tooling. The overhead of a workflow exceeds the cost of an occasional stale page.
Medium stakes — runbooks, onboarding, shared standards. Keep the lightweight review, but make drift visible. You want the page itself to say that it was approved at version 7 and is now on version 9. Editing stays open, because these documents need to be fixable by whoever finds the error.
High stakes — regulated procedures, released specifications. Restrict editing after approval, and keep an explicit record of who approved which version and when. Here the friction is the point, and the audit trail has to survive people leaving.
The mistake worth avoiding is applying the third pattern to the first category. Heavy approval workflows imposed on ordinary documentation produce pages nobody wants to touch, which get worked around, which is how you end up with the real runbook in a private chat.
The single question that decides it
Ask what happens today when someone edits a page that was approved last month.
If the honest answer is "we would probably not notice", you have identified your gap — and it is narrower than "we need an approval workflow". You need approvals that know which version they belong to.
---
*Approve & Lock for Confluence covers that specific gap: approvals bound to a version, a Stale state the moment a page changes, optional edit locking, and a dashboard of which approved pages have drifted. It runs entirely on Atlassian infrastructure, with no external servers.*