What a Confluence page properties report gives you
A Confluence page properties report is a table on one page that collects small blocks of metadata from many other pages. Each source page holds a two-column table of keys and values (Owner, Status, Next review). The report finds every page with a given label and shows one row per page, with one column per key. Put it on an index page and you have a policy register, or a register of any other documents.
It takes two macros working together:
- The page properties macro sits on each source page and wraps the metadata table.
- The page properties report macro sits on the register page and pulls those tables together, filtered by label.
Note: In Confluence Cloud, Atlassian now calls these the content properties macro and the content properties report macro. They are the same macros under a new name, so if you search the macro list for "page properties" and find nothing, search for "content properties" instead. This article uses the older names, which most people still search for.
If you are deciding how to run policies in Confluence more broadly (owners, locked editing, approvals, retiring old policies), start with Confluence policy management: beyond a wiki page. This article is the detailed how-to for one piece of it: the register.
Plan your policy register fields first
The keys you type on each page become the column headings in the report, so decide them once before you touch any page. For a policy register, these fields cover what people usually ask about:
| Key | Example value | Why it is there |
|---|---|---|
| Owner | Head of Engineering | One accountable person or role per policy |
| Status | Approved | Draft, Approved, Changes pending or Retired |
| Version | 3.1 | The version number people refer to in conversation |
| Last approved | 2026-03-04 | When the current text was signed off |
| Next review | 2027-03-04 | When the owner must review it again |
| Approver | CTO | Who signs off changes |
Three decisions save a lot of cleanup later:
- Fix the spelling of every key. "Next review" and "Next Review Date" are different keys and become different columns.
- Fix the status vocabulary. Pick four or five statuses and use only those.
- Write dates as YYYY-MM-DD. A date like 2027-03-04 is unambiguous for readers in any country, and it still sorts in date order if the report treats it as plain text.
Step 1: add the page properties macro to each page
Do this on every page that should appear in the register.
- Open the policy page in the editor and put your cursor where the metadata should go.
- Type
/to open the macro list, then type "content properties" (or "page properties") and choose the macro. - Inside the macro, insert a table with two columns: keys on the left, values on the right. One row per field.
- Format the left column as a header column, so the keys stand out as labels.
- Fill in the values for this page and publish.
The macro has two optional settings worth knowing about:
- Hidden. Hides the table on the page itself while still feeding the report. For policies, leave it visible so readers see the owner and review date.
- ID. Only needed if one page holds more than one properties macro and a report should read just one of them. A register rarely needs it.
Tip: Space admins can build the properties table into a space template. Every new policy page created from the template then starts with the right keys in the right order, which removes the most common source of empty columns.
Step 2: label every page in the document register
The report finds pages by label, not by location. Add the same label, for example policy, to every page that belongs in the register. You add labels from the page's labels area; where it sits in the page view has moved between Confluence versions, so look for "Labels" in the page details if you don't see it straight away.
Labels in Confluence Cloud are lowercase and can't contain spaces. Capitals are converted to lowercase, and a space becomes a hyphen, so typing "Security Policy" gives you security-policy.
If you created a template in step 1, add the label to the template too. Labels on a template are applied to every page created from it, so new policies join the register automatically.
For other document registers, use one label per register (procedure, runbook).
Step 3: add the page properties report to an index page
Create the register page, for example "Policy register" under your Policies parent page. Then:
- Type
/and search for "content properties report" (or "page properties report"). - In Label, enter the label from step 2. This is the only required field.
- Add a space filter (In space) with the space your policies live in. This keeps pages with the same label in other teams' spaces out of your register.
- Optionally, add With ancestor to limit the report to one page tree.
- Insert the macro and publish the page.
The report shows a first column with a link to each page, followed by one column per key it found.
Step 4: choose columns and sorting
Out of the box the report shows every key from every matched page. Tidy it up with the display settings in the macro:
| Setting | What to enter for a policy register |
|---|---|
| Title column heading | Policy (instead of the default "Title") |
| Columns to show | Owner, Status, Last approved, Next review |
| Sort by | Next review |
| Reverse sort | Whichever setting puts the soonest review first |
| Max results per page | Up to 30; more rows go onto further pages of the table |
Both Columns to show and Sort by must use the key names exactly as they appear in the properties tables. If a key name contains a comma, put it in quotes in the column list. Sorting on Next review puts the policies that need attention at the top, so the register doubles as a monthly checklist.
Common page properties macro gotchas
When a register comes out empty, half empty or oddly shaped, it is almost always one of these:
- The table isn't two columns inside the macro. The properties must be a table inside the macro body, with keys in one column and values in the other. A table placed just below the macro, or a three-column table, won't report the way you expect.
- Header row and header column together. The table can have a header row or a header column, not both. For the vertical layout above, use a header column only.
- Macros in the key column. Keys become column headings, so the left column can't contain macros. Keep keys as plain text.
- Labels that don't match.
policyandpoliciesare different labels. Check the label on a page that is missing against the label in the report. - Keys that don't match. One page with "Next Review" instead of "Next review" is a different key, so expect its value in a column of its own and a blank cell where it should be.
- Restricted pages. Confluence never shows view-restricted content to people who can't view it, in macros or anywhere else. The report you see may have rows your colleagues don't, and an auditor with limited access may see a shorter register than yours.
- Only the first page of results. The report shows at most 30 rows at a time and pages the rest. Check the pagination before concluding a policy is missing.
- The register page has the label too. Keep the register page itself out of the label, so it doesn't list itself.
Where a hand-maintained document register falls short
A page properties report is a good register for documents where the metadata changes rarely and nobody needs to prove it. For policies that support a SOC 2 audit, its limits show quickly.
The values are whatever someone typed
"Approved, 2026-03-04" is text in a table cell. Nothing checks it against an actual approval, nothing ties it to the page version that was approved, and anyone who can edit the page can change it. When the owner edits the policy the next day and forgets to set the status back to "Changes pending", the register still says Approved.
Updating the register edits the page
The properties table is part of the page body. Confluence creates a new page version every time someone publishes an edit, so changing the status or the review date adds a version to the policy's history even though the policy text didn't change. Policy version control and approvals auditors accept covers why that matters.
Dates don't remind anyone
A Next review column sorted ascending shows what's due, but only to someone who opens the page. And if the last approval was never recorded, the review date is wrong and nothing tells you.
A policy register in Confluence without typed properties
Compliance in a Box is a Confluence Cloud app that manages SOC 2 policies as ordinary Confluence pages in a dedicated compliance space. Instead of a properties table on each page, it keeps each policy's owner, approvers, approvals and review schedule in its own records, and shows them on the Policies tab of the app.
The Policies tab lists every policy with:
- Status: Draft, Pending approval, Approved or Changes pending, worked out from the approved version, any pending submission and the current Confluence page version. Nobody types it, so an edit after approval shows up as Changes pending on its own.
- Owner: the person assigned by a Compliance Admin under Settings, Owners & approvers.
- Approved version: the approved page version and approval date, for example "v8 · 2026-09-30", linked to that exact version in Confluence even if the page has been edited since.
- Next review: the latest approval date plus the review cadence (12 months for the SOC 2 policies), flagged Review due from 30 days before and Overdue after.
- Acknowledged: the share of the policy's audience that has acknowledged the approved version, shown to Compliance Admins and to each policy's owner.
Filter buttons narrow the list to Awaiting my approval, Required for me, Mine or Review due. None of this lives in the page body: the app never edits a policy page's text after creating it, so keeping the register current adds no versions to the policy's history. The same status also appears in a byline under each policy's title, so readers on the page see it too. The details are in the Policies tab chapter of the user guide, and Periodic reviews explains how review dates are set.
If your policies already live in another Confluence space, Compliance Admins can copy their text into the app's policy pages with the import wizard (see Importing and custom policies). Each imported policy then goes through approval as usual. A page properties report is still a fine register for the documents the app doesn't manage, such as runbooks and team procedures.
FAQ
Why is my page properties report empty?
Check the label first: it must match exactly, including hyphens. Then check that each source page has the properties table inside the macro as a two-column table, and that you have permission to view them.
Where did the page properties macro go in Confluence Cloud?
Atlassian renamed it. In Confluence Cloud, search the macro list for "content properties" and "content properties report" to find the same two macros.
Can a page properties report cover more than one space?
Yes. Enter several spaces in the report's In space filter and it returns labeled pages from any of them. Several labels in the Label field work the same way, so one report can combine registers. Each viewer only sees rows for pages they have permission to view.
Does updating a page property create a new page version?
Yes. The properties table is part of the page, so publishing a change to it creates a new version like any other edit.