Document lifecycle and publishing

Confluence draws no distinction between a working version of a page and a published one. Every edit is visible to anyone with read access the moment it’s saved. For compliance content, internal policies, customer-facing documentation, or anything else where readers should only see an approved version, that’s a problem. The fix uses two Confluence spaces and Aura’s Publish page action to bridge them.

The pattern

Set up two spaces. The working space is where authors draft, revise, review, and approve. The published space is where everyone else reads. Restrict the working space through Confluence’s standard space permissions so only authors can view it; leave the published space open to whoever should read the policies. To readers, the working space effectively does not exist — they only see finished versions in the published space.

The bridge is a workflow on the working space that takes a page through draft, review, and approval states. The transition into the approved state runs a Publish page action that copies the current version to the published space, overwriting the previous published copy if one exists. Authors keep iterating in the working space without changing what readers see. When the next round of edits is approved, the published copy updates.

Aura does not enforce the separation between the two spaces; Confluence’s space-level permissions do. Aura runs the workflow on top of whatever permissions you have in place. Set the working space to author-only and the published space to whoever should read, and the pattern works.

How approval and publishing fit together

The workflow shape is straightforward. A minimal version has three states: a Draft state where authors edit, an In Review state with an approval transition, and a Published state whose action list contains the Publish page action. Reviewers configured on the approval transition sign off; once the threshold is met, the page transitions into Published, the publish action runs against the public space, and the next reader who hits the published page sees the new version. See Approvals for the reviewer and threshold model and Publish page for the full set of action options.

The pattern works because Publish treats re-runs as updates. The first time a page enters Published, the action creates a new page in the published space and stores a mapping back to the source. Every subsequent run updates that same destination page in place, so the readers’ view of “the policy” is one stable URL whose content advances version by version. Internal links between working pages are rewritten on publish to point at the corresponding published pages where Aura can find them, so a policy that links to other policies behaves the same way for readers as for authors.

What gets copied is the page body, its attachments, and — if you tick the option — its labels. Restrictions are deliberately not copied: a viewer restriction in the working space exists to gate authors, not to limit who can read the published policy, and copying it would defeat the point of a public space.

Iterating without breaking the reader’s view

Once a page has been published, authors can edit it freely in the working space. The page transitions back to Draft (manually or through an On page edit event configured on the Published state), the next round of changes goes through approval, and only when reviewers sign off does the published page update. Readers see the previously-approved version the entire time. No window exists in which a half-edited draft is visible publicly.

One consequence worth knowing: each transition into Published is a fresh publish. If you bounce a page through Draft → In Review → Published twice with no real changes between, the publish action runs twice. That is not destructive — it overwrites the destination with the same content — but it counts as an edit on the published copy and shows up in its history.

Applying the workflow at scale

A working space full of policies needs the workflow on every one of them. Apply it once across the space using bulk apply, and configure an auto-apply rule so any new page authors create in the working space picks the workflow up automatically. See Applying workflows for the bulk-apply and label-rule details. From there, every new policy starts in Draft, every change goes through review, and the published space stays clean.