Overview

Confluence treats every page the same. There’s no built-in notion of a draft versus a published page, no way to require sign-off before something goes live, no concept of content going stale and needing a re-review. Teams paper over this with naming conventions, parent-page hierarchies, and reminders in chat — none of which the platform actually enforces.

Aura Workflows fills that gap. It layers state, approval, and lifecycle on top of Confluence’s native page model without replacing it. Pages stay pages; the editor, permissions, and history work the way they always did. Aura adds a control plane on top: a page knows which workflow it’s running, what state it’s in, who needs to approve the next move, and what should happen automatically when it gets there.

The core concepts

A workflow is a template. It’s the shape of a process — Draft to In Review to Published, or Captured to Triaged to Resolved, or whatever your team needs. You design it once in the Workflow Builder and then apply it to pages. The workflow itself doesn’t do anything; it’s the rules.

When a page picks up a workflow it becomes an instance sitting in some state. States are the boxes in your diagram: a page is in exactly one of them at a time. States are connected by transitions, which are how a page moves from one state to the next. A transition can require an approval — one or more reviewers vote, and the page moves only when the configured threshold is met. It can offer a manual selection, where any user picks the next state from a list. Or it can fire automatically: on a page edit, or after a fixed expiration. A state can also be terminal, with no outgoing transitions.

States carry behavior of their own. Each state runs actions when a page enters it — sending email, restricting access, publishing into another space, bumping the official version, applying labels, rewriting the title. Two more pieces tie it all together. Variables parameterize a workflow per page, so a single template like “ask the page owner’s manager for approval” can serve hundreds of pages without hard-coding names. Metadata fields capture structured data per page — a ticket number, a priority, a review date — that lives alongside the workflow.

How a workflow lives on a page

Workflows are applied either per page or in bulk. A user can attach a workflow to a single page from the page byline. An admin can scope a workflow to an entire space, or to every page carrying a particular label, so new pages pick it up automatically. See Applying workflows for the rules around bulk application and what happens when a page matches more than one.

Once applied, the workflow surfaces in two places. The byline above the page title shows the current state, the available transitions, and any approval that’s mid-flight — that’s where users vote, comment, and trigger the next move. Embedded macros expose the same information inside other pages, so an index or dashboard can list every page in a given state. Reviewers approve or reject; actions run on entry to each new state; expiration timers tick in the background. Eventually the page lands in a final state or, if it has an expiration configured, gets pushed onward automatically when the clock runs out.

Variables resolve the moment they become relevant — when an approval is created, when an action sends mail. Editing a variable after the fact won’t retroactively change a vote that’s already collected or an email that’s already gone out. Actions inside a state run in two phases: a small set of structural actions first, then everything else in parallel, with no guaranteed order within a phase. Both behaviors matter once a workflow is doing real work, so they’re worth knowing up front.