How to lock a Confluence page after approval
Once a page has been reviewed, the obvious way to keep it trustworthy is to stop people editing it. Confluence supports this directly through page restrictions, and for a lot of teams that is the whole solution.
It is worth understanding precisely what restrictions do before relying on them, because there are a few things people expect them to do that they do not.
Applying a restriction
On any page, open the restrictions control — the padlock near the top of the page — and you can set:
- Anyone can view and edit — the default, inherited behaviour.
- Anyone can view, only some can edit — the setting you want after approval.
- Only some can view or edit — restricts reading as well, which is a different requirement and usually not what an approval workflow wants.
For a reviewed page, the middle option is normally right: everyone who needed the document can still read it, and only a named group can change it.
Four things that surprise people
Restrictions are inherited by child pages. A view restriction on a parent cascades down the tree. This is useful when you mean it and confusing when you do not — restricting one approved page can quietly affect everything nested under it.
Space admins and site admins can still edit. A restriction is not a hard lock against everyone. Anyone with the right administrative permission can change the page, and depending on your configuration they may be able to remove the restriction itself. Restrictions are a strong deterrent against accidental edits, not a guarantee against determined ones.
Restrictions do not record why. The page becomes uneditable, but nothing on it explains that this is because it was approved on a particular date at a particular version. Six months later, someone finds a locked page and has no idea whether the lock is meaningful or left over.
Locking does not stop the page going out of date. This is the one that matters most. A locked page is protected from *edits*, not from *reality*. The hostname it documents still changes; the procedure it describes is still superseded. Locking converts one failure mode (silent drift) into another (confidently wrong, and now hard to fix).
When locking is the right call
Locking works well when the content is genuinely finished and the cost of a wrong edit is higher than the cost of friction:
- Signed-off policy documents that are reissued rather than amended.
- Released specifications, where the point is that the released version is fixed.
- Anything where an unreviewed change would be a compliance problem rather than an inconvenience.
In those cases, restrict editing to a small group and accept the friction. That is the friction working as intended.
When locking is the wrong call
Locking is a poor fit for living documentation — runbooks, onboarding guides, architecture notes that evolve. Here the cost shows up as staleness. The person who spots the error is not in the edit group, so they mention it in a comment, or in chat, or not at all. The page stays wrong and stays locked, which is worse than being wrong and editable.
There is a reasonable middle path: let the page stay editable, but make edits visible against the approval. Rather than preventing the change, record that the approved version was 7, note that the page is now on version 8, and surface that difference. Anyone reading knows the sign-off no longer covers what they are looking at, and whoever fixed the hostname was not blocked from doing so.
That approach trades enforcement for honesty. Which is right depends entirely on whether your risk is *unauthorised change* or *undetected drift* — and for most internal documentation, it is the second.
A practical default
For most teams:
- Use restrictions on the small set of documents where an unreviewed edit is genuinely unacceptable.
- Leave everything else editable, and make sure an edit to an approved page is *visible* rather than silent.
- Whichever you choose, write down somewhere on the page which version was approved and by whom, so a future reader can tell whether the sign-off still applies.
Point three is the one people skip, and it is the one that makes the other two worth anything.
---
*Approve & Lock for Confluence can optionally apply an edit restriction when a page is approved, and flips the page to Stale if it changes anyway — so a locked page and an edited page both tell the truth. It runs entirely on Atlassian infrastructure.*