Why an approved Confluence page stops being approved
Someone reviews a runbook. They read it, they agree with it, they say so in a comment: *approved*. Three weeks later a colleague fixes a hostname, adds a step, and removes a paragraph that no longer applies. The comment still says approved.
Nothing went wrong procedurally. Everyone behaved reasonably. And yet the page now carries a sign-off that nobody gave to the text currently on the screen.
An approval is a statement about a version
This is the distinction that most approval processes lose. When a reviewer signs off, they are not endorsing *the page* — a page is a moving object with a history of dozens of revisions. They are endorsing the exact bytes they read, which is to say one specific version in the page history.
Confluence models versions properly. Every save creates one, and you can see the whole sequence under page history. What is missing is any link between a sign-off and the version number it belongs to. The approval floats free of the thing it was about.
Once you see approval as a claim about a version, the failure mode is obvious. The claim was true when it was made. It is still sitting there, unchanged and unqualified, after the thing it described has moved.
Why this matters more than it looks
For a lot of content it does not matter much. A meeting note that drifts is a meeting note.
It matters when someone downstream is *relying* on the sign-off:
- Regulated documentation. An auditor asks who approved the current version of a procedure. "Someone approved a version of this page in March" is not an answer.
- Runbooks and incident procedures. These get read under pressure, by people who have no time to audit whether the reviewed content is the content in front of them.
- Security and architecture decisions. The approval is doing real work — it is the record that a specific design was accepted.
- Anything a customer or regulator can request. The gap between "approved" and "approved *as it now reads*" is exactly the gap that gets found later.
The common thread is that the approval is being treated as a *current* statement when it is a *historical* one.
What Confluence gives you natively
Quite a lot of the raw material, and it is worth using before reaching for anything else:
- Page history records every version, who changed it and when. The evidence of drift is always there — it just has to be checked manually.
- Page restrictions let you limit who can edit a page. Applied after review, they stop casual drift.
- Comments and @mentions are how most teams record sign-off today, and for low-stakes content that is genuinely fine.
- Watching a page notifies you when it changes, so a reviewer can at least find out.
What none of these do is connect the sign-off to a version and then *react* when the version moves. That connection has to be made by a human noticing, and humans reliably stop noticing.
Three ways teams handle it
Lock the page after approval. Restrict editing to a small group once review finishes. Honest and simple. The cost is friction: every correction, however trivial, now needs someone with rights, and pages that are annoying to fix tend to stay wrong.
Re-review on a calendar. Every quarter, walk the reviewed pages and confirm they still hold. This works, and it is what most compliance processes fall back on. The weakness is that a page can be wrong for eighty-nine days before anyone looks, and that the review load grows with the documentation set.
Bind the approval to the version. Record which version was approved, and treat any later version as not-yet-approved. Nothing is blocked and nothing is lost — the page simply stops claiming to be approved once it stops being the reviewed text. The drawback is that it needs tooling: the version number has to be captured at sign-off and compared on every subsequent change.
The question worth asking
Whatever you choose, the useful test is this: if someone edits an approved page right now, what happens?
If the answer is "nothing visible, and the approval still reads as current", then the approval is no longer telling anyone the truth — and the longer that goes on, the less any sign-off on any page is worth.
---
*Approve & Lock for Confluence binds each approval to the page version that was reviewed and flips the page to Stale the moment it changes, with an audit trail of who approved which version and when. It runs entirely on Atlassian infrastructure.*