If you have been through ISO 27001 or SOC 2, an auditor has asked you a version of this: show me that this policy was reviewed and approved, by whom, and show me that the version in front of me is the approved one.
Confluence Cloud has no native answer. CONFCLOUD-6373 asks for page approval workflows and has 560 votes. The page has version history, which tells you that it changed and who changed it, and nothing about whether anyone signed it off.
Why the usual workarounds fail an audit
- A label like
approved. Cheap and immediately wrong: a label has no version. Someone approves v4, someone else edits to v7, and the label still says approved. It is now evidence of something that is not true. - A table at the top of the page. "Approved by Jane, 3 March." It is a table. Anyone can type in it, including the author, and nothing ties the row to the version it approved.
- A Jira ticket per approval. Audit-defensible and heavy enough that people route around it. The ticket and the page also drift: the ticket says approved, the page has moved on.
The failure is the same in all three. Approval gets recorded against the page rather than against a version of the page. The entire value is in that distinction.
What a working approval needs
- Pinned to a version. The record says approved at v4, not approved.
- Automatically invalidated. When the page passes the approved version the state turns stale on its own, with nobody remembering to clear anything.
- An approver list that is not self-service. The author cannot be the sole approver.
- Visible on the page. Someone reading it should see the state without knowing where else to look.
- Queryable. "Every approved page in this space" has to be answerable across hundreds of pages, which means CQL, which means the state lives in an indexed content property.
- Exportable. Who approved which version, when.
How far you can get yourself
The REST API will take you part way. Write a content property holding the approved version:
PUT /wiki/api/v2/pages/{id}/properties
{"key": "approval", "value": {"state": "approved", "approvedVersion": 12}}
Then compare approvedVersion to the page's current version on read, and you have
points 1 and 2. What you cannot reasonably build without an app is the byline badge in front of
every reader, space-level approver configuration, and the guard rails that turn a stored field
into a control: approvers only, no self-approval, one decision per approver, quorum, and version
drift rejected rather than ignored.
The app
Page Approvals for Confluence implements the state machine directly: none to pending to approved or rejected, and approved to changed since approval the moment the page's version passes the approved one. Re-requesting on a new version discards the decisions on the old one, because those were decisions about different text.
Per-space approvers and groups, a quorum of distinct approvers, no self-approval unless you deliberately allow it, due dates, and a dashboard of pending, overdue and stale pages. State is an indexed content property, so CQL finds approved pages. The audit CSV gives you the who-approved-which-version table the auditor asked for.
Two limits worth knowing before you install rather than after. Reminders are not emailed: the app makes no outbound call at all, which is what lets it run entirely on Atlassian, so the overdue view is the reminder. And the CQL value can lag the badge, because the page-updated trigger runs with no user and on some sites the app identity cannot write a page property in that context. The badge, dashboard and CSV read the record directly and are always current.
Written by Abaho Katabarwa at Katabarwa Labs. We build small, single-purpose Atlassian and Azure tools that run entirely inside your own tenant. Questions: support@katabarwalabs.dev.