What a Confluence approval workflow has to prove
Teams set up a Confluence approval workflow because some pages carry weight: a security policy, an onboarding procedure, a quarterly access review. The hard part isn't collecting the yes. It's making sure the yes still means something three months later, when the page has been edited twice and someone asks whether the current text was ever approved.
"Approved" should mean all of the following:
- A named approver. A real person, identified by their account, not "the team" or "management".
- A specific version. The approval covers one version of the page, identified by its version number in the page history. Not "the page".
- Every required approver. If a page needs sign-off from security and legal, one of them saying yes isn't approval.
- Later edits aren't silently covered. When the page changes after approval, it should be obvious that the new text isn't approved yet.
- A record that survives. Who approved what and when should still be readable after the page is edited, restored or reorganized, and nobody should be able to quietly rewrite it.
Each of the usual methods gets some of these right.
Ways to approve pages in Confluence today
An approval table in the page
The most common pattern is a small table at the top or bottom of the page: approver, role, date, decision. The approver edits the page and fills in their row. Every reader can see it.
The weakness is that the record sits inside the thing being approved. Anyone with edit rights on the page can change the table, including the dates and names. Filling in the row is itself an edit, so it creates a new version of the page. And when someone later edits a paragraph, the table keeps saying "Approved" above text nobody approved.
A comment or @mention sign-off
The author mentions the approvers in a comment ("@Dana please review and approve"), Confluence notifies them, and they reply "Approved". Comments carry a name and a timestamp, and they don't change the page body, so there's no version noise.
But a comment applies to the page, not to a version. A comment written last spring sits under this autumn's text and looks exactly the same. Nothing tells you who hasn't replied yet.
Page status and labels
Confluence Cloud lets you set a content status on a page. The default suggestions are Rough draft, In progress and Ready for review, and space admins can change the list (up to five statuses per space), so you can add one called "Approved". Labels are similar: anyone who can edit the page can add a label such as approved, and you can then find every page with that label.
Both are good signals for readers and easy to search. But they are markers, not records: anyone who can edit the page can change them, and neither says who approved the page or which version they approved. A status of "Approved" on a page edited yesterday is a claim, not evidence.
Inline tasks for approvers
You add a task per approver on the page ("@Dana approve version 12") with a due date. Confluence notifies each assignee, the task appears in their task list, and it turns red once it's past due. This is the best manual option for chasing: you can see at a glance who hasn't ticked their box.
The gaps are the familiar ones. Adding the tasks is a page edit, so it creates a version of its own. A ticked box doesn't record which text the approver read. And if the page changes after the tasks are ticked, the ticks stay.
Confluence's built-in approvals
On the Premium and Enterprise plans, Confluence has a native approvals feature. Once a space admin turns on statuses with approvals for the space, you start an approval from the page's content status menu, add the approvers and optionally a due date and a message. Approvers respond with Approve or Request changes, and an activity log keeps past approval cycles: who requested approval, who responded, their comments and when. Space admins can also require approval before new pages are published. People need edit permission on the page to request or respond to an approval.
If you're on one of those plans, test it before relying on it for formal sign-off: check how it treats an edit made after the page is approved, and whether the record shows you which page version each approver saw.
| Method | Good at | Where it breaks |
|---|---|---|
| Approval table in the page | Visible to every reader | Editable by anyone with edit rights; every entry adds a version; stays "approved" after edits |
| Comment or @mention | Name and timestamp, no page edit | Not tied to a version; no list of who is outstanding |
| Status or label | Easy to see and search | No record of who or which version; easy to change |
| Inline tasks | Notifications, due dates, a clear outstanding list | Adding them is an edit; a tick doesn't name the version |
| Built-in approvals | Native request, response and history | Premium and Enterprise only; test how it handles later edits |
Where manual Confluence document approval breaks down
Look across the methods and the same three problems keep coming back.
- The version isn't part of the approval. Confluence keeps a full version history and creates a new version every time someone publishes an edit. That history is the raw material you need, but none of the manual methods connects an approval to a particular entry in it.
- Edits after approval go unnoticed. The approval marker (a table row, a tick, a status) stays put while the text underneath changes. Readers see "Approved" and assume it covers what they're reading.
- "Everyone must approve" depends on someone checking. With three approvers and two ticks, the page looks almost done. Nothing stops it being treated as approved.
That matters for anything an auditor or a customer might ask about. For the auditor's view of policy versions in particular, see policy version control and approvals auditors accept.
A simple Confluence approval process that holds up
If you only have a handful of pages that need approval, you can run a sound process with plain Confluence. The trick is to make the version number part of every step, and to keep the record somewhere other than the page being approved.
- Decide the approvers before you start. Write down who must approve each page, and make sure at least one of them isn't the author.
- Finish editing, then freeze. Publish the final edit with a version comment that summarizes the change. Open the version history and note the version number, for example version 14.
- Request approval of that version. Mention each approver in a comment that names the version: "Please approve version 14. Changes since version 11: new section on contractor access." Add a due date if you use tasks.
- Approvers review the diff, not just the page. In the version history, select the last approved version and the new one and compare them. Approvers should reply naming the version: "Approved version 14."
- Restart if the page moves. If anyone publishes an edit before every approver has replied, the request is void. Freeze again, note the new version number and ask again.
- Record the outcome outside the page. Keep an approval log on a separate page that only a few people can edit: page, version, approvers, decision dates, change summary. On Standard and above, use page restrictions to limit who can edit both the log and the approved pages. The Free plan doesn't support page restrictions.
- Check the version before you rely on it. Anyone citing the page as approved should compare the current version number with the one in the log. If they differ, the current text needs a new approval.
Important: if you record approvals in a table on the page itself, adding the row is an edit, so the page's current version is never the one that was approved. Log the version the approvers actually read, not the version that holds the table.
Tip: decide in advance which edits need a fresh approval. A changed rule does. A fixed typo arguably doesn't. Write the rule down. The Confluence policy management guide covers the rest of the setup around approved pages: owners, structure, review dates and restrictions.
Approving pages in Confluence with Compliance in a Box
Compliance in a Box is a Confluence Cloud app that runs a SOC 2 compliance program in one Confluence space. Approvals in it work on the pages it manages in that space: policy pages and the evidence pages its recurring activities open each period. It runs the process above for you, with the version binding enforced rather than remembered.
- Named approvers, fixed at submission. A Compliance Admin assigns each policy an owner and 1 to 10 approvers under Settings, Owners & approvers. The approvers of a submission are fixed when it is submitted, so changing them mid-review doesn't change who decides.
- Approval of an exact version. The owner edits the page in Confluence as normal and selects Submit for approval, either in the app or from the byline under the page title. The app records the page version and a fingerprint (hash) of its content, and the owner describes the change under What changed?. See editing and submitting a version.
- Every approver must approve. The version is approved only when the last approver approves. One rejection, which needs a reason, sends it back to the owner. Approvers see Your approval needed in the page byline and a task in My Tasks.
- Edits cancel the submission. Any published edit to a page that is waiting for approval cancels the submission, and an approver who tries to decide on the old version is told to ask the owner to resubmit. Nobody approves text they haven't seen. See withdrawn and cancelled submissions.
- Later edits are visible. Editing an approved policy doesn't move the approval. The approved version stays as it was, and the policy shows Changes pending until the new text is approved.
- A record that survives. Every submission, decision and cancellation is written to an append-only audit log whose entries can't be edited or deleted. The generated Policy Approval Log lists each submission with a link to the exact page version, every approver's decision, and self-approvals flagged. See the Policy Approval Log.
Evidence pages follow the same rules: the activity owner submits a period's evidence page, every approver must approve that version, and an edit before approval cancels the submission (see reviewing and approving evidence). Policy pages are also locked so that only the owner and Compliance Admins can edit them, using Confluence page restrictions, which need Standard or above. For how approvals fit with acknowledgements and the rest of a SOC 2 program, see running a SOC 2 program in Confluence.
FAQ
Does Confluence have a built-in approval workflow?
On the Premium and Enterprise plans, yes: approvals can be started from a page's content status menu once a space admin turns them on. On Free and Standard you rely on the manual methods above, such as comments, tasks and an approval log.
What should happen to an approval when the page is edited afterwards?
The approval should stay with the version that was approved, and the edited page should show as not yet approved. If the edit happens while approval is still in progress, start the request again for the new version.
Can the author approve their own page?
Your process can allow it, but for anything an auditor will see, have at least one approver who neither wrote nor owns the page.
How do I show which version of a Confluence page was approved?
Record the version number from the page history at the moment of approval, alongside the approvers and the date. Anyone can then open that exact version from the history.