Skip to content

Read confirmations

Read confirmations are a way to require viewers of a page to acknowledge that they’ve read it. Turn them on for a page and a banner appears at the top asking each reader to confirm. Confirmations are recorded against the version of the page each user confirmed, so when the page is edited later you can see exactly who is still acknowledging an outdated version.

The feature is per-page. There is no workflow state, no transition, and no admin setup — anyone who can edit a page can enable confirmations on it.

Open the page and choose Aura Read Confirmations from Confluence’s content actions menu (••• in the page header → Apps).

Confluence content actions menu open with the Apps submenu expanded showing Aura Read Confirmations

The dialog that opens is the read-confirmations control panel for that page. Until anything is configured, it shows Read confirmations are disabled with an Enable for this page button — clicking that button is equivalent to flipping the Enable confirmations switch in the top-right corner. The banner appears on the page within seconds.

Aura Read Confirmations dialog showing the disabled state with an Enable for this page button and the Enable confirmations switch turned off in the top-right

The same switch turns the feature off again. Disabling removes the banner from the page but does not discard the confirmation history; if you re-enable later, the prior confirmations come back. To enable or disable, you need edit permission on the page.

While confirmations are on, a banner sits above the page body for every viewer who hasn’t confirmed yet. It reads Have you read this page? with a short instruction and a Confirm button. The banner shows the page’s current version number as a badge — a quick visual cue for what the reader is about to attest to.

Read-confirmations banner at the top of a Confluence page asking the reader to confirm they have read the page, with a version badge and a Confirm button

A click on Confirm records the confirmation against the user and the version of the page they’re looking at. The banner disappears for that user. Other readers still see it until they confirm too. Anyone with view access on the page can confirm; you do not need edit permission.

There is no comment field and no “decline” path. The feature is an acknowledgement, not an approval — for sign-off with vote thresholds, use Approvals instead.

Confirmations are version-scoped. Each one stores the page version that was current when the user clicked Confirm. The next time someone publishes a new version of the page in Confluence, every existing confirmation is now against an older version, and Aura treats it as stale.

For readers with a stale confirmation, the banner returns — in a different colour, with the heading A new version of this page is available. A View changes link opens Confluence’s built-in version-comparison view between the version they confirmed and the current one, so they can see exactly what changed before re-confirming.

Stale read-confirmations banner with a warning colour, a View changes link, and a Confirm button prompting the user to re-confirm the updated version

A user who never confirmed sees the same default banner as before — staleness only applies to people who had previously confirmed. When a stale user re-confirms, the new confirmation replaces the previous version reference and the banner clears for them again.

Re-open Aura Read Confirmations on an enabled page and the body of the dialog shows the Confirmed by list: every user who has confirmed, the date and time, and the version they confirmed against. The list is sorted with the most recent confirmations first, four per page.

A warning icon next to the version means that confirmation is now stale — the page has moved on since they confirmed. Hover the icon for Confirmed an older version of this page. There is no “remind” button; staleness surfaces in the overview so you can chase the right people through whatever channel you normally use.

Confirmed by list inside the Read Confirmations dialog showing several users with confirmation timestamps and version numbers, one row marked with a stale-version warning icon

Use the Search for user field at the top of the list to filter to a single person. This is the fast path when you want to check whether one specific reader has confirmed and which version they’re on.

If nobody has confirmed yet, the dialog shows No confirmations yet instead of the list. If you turn the feature off without anyone having confirmed, the dialog drops back to the Read confirmations are disabled view shown above.

On a published page produced through a workflow’s Publish page action, read confirmations are independent of the publish step. Enabling confirmations on a source page does not enable them on the published copy, and vice versa. If you want readers of the published version to acknowledge it, enable confirmations on the published page directly.

The version number tracked by a confirmation is the Confluence page version of the page the user is viewing. On a published copy, that is the version of the published copy, not the source — which is what you want, since the published copy is the document of record for those readers.

The clearest fit is mandatory-reading content where you need an audit trail: policies, compliance documents, security guidance, change announcements that affect a specific team. The version-scoped record means that six months later, when someone asks “who had read the most recent version of the security policy as of March?”, the Confirmed by list answers it directly.

For lighter signals — did anyone read this? — Confluence’s view analytics already tell you. Reach for read confirmations when the question is did this specific person attest to this specific version?.