Confluence Page Approval Workflow, Step by Step

If you've ever been asked to "just add an approval step" to a Confluence space, you've probably found the 2019 Community thread that comes up first. In June 2019 someone asked for a "multi-tier (each tier has three people) document approval workflow," and the first reply was "there's no approval workflow out of the box." That stayed true for seven more years. On Atlassian's public tracker, the best-known request, CONFCLOUD-4153, had been closed as Won't Fix back in 2011. It has 94 votes today.

Now it's changed: Confluence Cloud has a native page approval workflow. On 10 July 2026 Atlassian put native Approvals in Confluence into open beta for Premium and Enterprise. On 5 November we set it up on our test site with two test accounts, Elzi and Theo, as approvers. When Elzi approved, the page said 1/2 and stayed In review. It only turned Approved when Theo approved too, because every approver you name has to approve.

That all-or-nothing rule is the main limit, and it's the one the 2019 thread would hit: there's no "any one of these three" or "two of three." Approvers can't be groups either. Automation can start an approval but can't react to one. And on Standard you still only have content status, the coloured label next to the page byline (automation calls it page status), which any editor can change. The one exception is Verified, a built-in status that only page owners and admins can set.

So this tutorial does both. First the native setup, step by step, with what we saw on screen. Then the Standard version with content status and automation. At the end there's a multi-approver setup with our own app, Sentinel Vault, for teams that need any-one or minimum-N rules.

[[steps]]

1. Turn on the Confluence approvals beta for the site and the space (Premium or Enterprise).
2. Set the space rules: required approvers, approval expiry and the publish gate (the setting that makes a page wait for approval before it goes live).
3. Start an approval on a page and answer it as an approver.
4. Edit an approved page and see what happens to its approval.
5. On Standard, build Confluence approval automation with page status and know what it can't stop.
6. Create a multi-approver Confluence approval workflow with any-one, all or minimum-N approvers in Sentinel Vault.

Before you start: what the Confluence approvals beta and the other routes need

Note

Prerequisites

• Confluence Cloud. Everything in this tutorial is Cloud only.
• For Steps 1 to 4: the Premium or Enterprise plan. The support doc says "Approvals are available only on Premium and Enterprise plans."
• Roles: a Confluence product admin for Step 1, a space admin for the space settings, and edit permission on the page for anyone who asks for or answers an approval.
• For Step 5, the Standard route: content statuses on in the space (Space settings → General; the screen is called Status and approvals on our site and Avatars and status in Atlassian's content status doc), Confluence Automation, and a group of the people allowed to verify pages. Atlassian's recipe has an org admin create it in admin.atlassian.com under Directory → Groups.
• For Step 6: Sentinel Vault 8.26.0 on the site, and a space admin to set up its workflow.
• Our test run: our Confluence Cloud test site on 5 November 2026, with four accounts: a requester, two approvers (Elzi and Theo) and one editor who is neither (Iris).

When you're done you'll have a space where pages go to named approvers, a record of who approved and when, and a clear idea of where the native feature stops.

Approvals work on pages. The doc says they're "supported on pages, but not on live docs or blog posts." Live docs are Confluence's always-published pages, which have no drafts. If your team writes policies as live docs, keep reading, because live docs also block the publish gate in Step 2.

Then there's the status of the feature itself. The announcement title still says "Open Beta," and we couldn't find a general-availability notice anywhere (checked 5 November 2026). The Start approval menu item on our site carries a Beta tag too. So expect it to keep changing for a while.

Step 1 — Turn on the Confluence approvals beta for the site and the space

Approvals start switched off, and two people turn them on. The announcement puts it like this: "A product admin enables it for your site under Configuration → New features, then space admins turn it on per space under Space settings → Status and approvals."

1. As a product admin, go to Confluence administration (the settings for the whole site), then Configuration → New features in Atlassian's words, and select Turn on next to Approvals (Beta). The button changes to Turn off, which means the feature is on for the site.
2. As a space admin, go to Space settings → General → Status and approvals in the space and set the mode to Enable statuses with approvals. The approval statuses and the Approvals section appear on the same screen.

There's a shortcut to the first one. Even before the feature is on, a page's Status menu shows Start approval. On our site, selecting it opened a small promo whose Enable in Settings button went straight to New features.

If the approval settings don't show up, check the mode. The doc warns that "Choosing Enable statuses only or Disabled hides the approval settings." And if turning the feature on fails with "Something went wrong," see If it didn't work at the end.

Step 2 — Set the space rules: required approvers, the publish gate and expiry

The same Status and approvals screen has three switches under the approval statuses. They decide who approves, how long an approval lasts and whether a page has to wait for one.

1. To fix who approves, turn on Required approvers and add the people, up to 5. Requesters then can't add or remove reviewers on pages in this space.
2. Optional: to make approvals lapse, turn on Set approval expiration and pick a period of up to 1 year.
3. Optional: to make pages wait for approval before they go live, turn on Require approval before publishing. With live docs on, the toggle stays greyed out and reads "This setting can only be enabled when live docs are disabled in this space."

Required approvers is a good fit for a policy space where the same people always sign. The screen calls it "Limit all approvals in this space to specific approvers (maximum of 5)," and the announcement adds that "requesters can't add or remove reviewers" while it's on.

Expiration covers yearly re-reviews. The screen says "We'll notify the page owner and requester before the expiration date."

The publish gate needs a closer look. The screen describes it as "Require approval before publishing or updating any page." That wording matches the October update Atlassian added to the beta announcement, which says the gate now covers "every publish meaning it applies to existing page edits." The support doc, published in July, still says "new pages must have approval before publishing." So the doc lags the product here. If live docs are on, the Manage live docs link on the same screen is where you turn them off. Our sources don't say what that does to the live docs you already have, so check that before you switch.

This is the one native setting our run didn't reach. We left live docs on in our test space, so the toggle stayed greyed out and we didn't test the gate itself. Anything this article says about the gate comes from Atlassian's description.

Step 3 — Start an approval on a page: every approver has to say yes

You start an approval from the page's status menu, the one you already use for a content status. Our test page was at Ready for review before we started. Start approval sits at the bottom with a Beta tag.

The panel asks for approvers, a message (up to 250 characters) and an optional due date. Approvers get reminders and "can still respond after this date," as the panel puts it.

1. On the page, open Details (the i button), then Status, and select Start approval. The approval panel opens.
2. In Approvers, add the people who need to approve (up to 10), then select Start. The byline changes to In review and a banner reads "Approval in progress 0/2 approved" (with two approvers, as in our run).
3. As each approver, open the page and select Respond in the banner below the byline, then Approve or Request changes. The banner counts each approval.

Approvers are people only. We typed the group names confluence-users and site-admins and got "No options." In the same field, Elzi came up on the first try. So did Theo. You can't approve your own page, either: adding ourselves gave "You can't add yourself as an approver."

Elzi approved first. The banner moved to 1/2, and the page stayed In review.

When Theo approved too, the byline turned Approved. To confirm it worked, check the banner under the byline. You should see this:

Page approved 2/2 approved 

The space settings define it the same way: "Approved: All approvers have approved the page."

One Request changes is enough to hold the page back: per the space settings, the page moves to Changes requested ("At least one approver requested changes to the page"). The doc says approvers "can edit your response until the approval is complete."

Confluence keeps the history in the page's activity log. Per the doc, it "shows past approval cycles, including who requested approval, who approved the page or requested changes, any comments, and when each decision happened." If an auditor asks who approved a page, that log is the answer. Open it once on a test page to see what it keeps.

Step 4 — Edit an approved page: the approval is cleared, not kept

Here's what happens with the publish gate off, as it was in our space. We did this as the person who'd requested the approval.

1. Edit the approved page and select Update. Confluence stops you with "Proceed with replacing approved content?"
2. Select Confirm. The edit publishes, the approval is gone and the byline goes back to the status the page had before.

On our page the byline went back to Ready for review. Nobody was asked to approve again.

So with the gate off, an edit doesn't sneak past an approval. It removes it. After any edit, check the byline: if it no longer says Approved, start a new approval as in Step 3. Only the requester's edit is covered here; nobody else edited this page. With the gate on, Atlassian's October update says "every subsequent edit will also require a fresh approval before it can go live." Step 2 explains why that part is Atlassian's word.

Where the native document approval process in Confluence stops

None of this is hidden. Atlassian's own tracker lists the gaps.

Every approver has to approve, and there's no quorum

CONFCLOUD-85363 was opened on 28 October 2026 and has 12 votes. It says "Native Confluence Cloud page approvals currently require approval from every designated approver." It also says there's no setting for "approval by any one of the designated approvers (1-of-N), or a minimum threshold/quorum, such as 2 of 3 approvers."

The workaround field reads "Currently there is no known workaround." Our 1/2 test in Step 3 matches it.

So the 2019 ask, three people per tier, works natively only if all three sign. If one of them is on holiday for two weeks, the page waits two weeks. Nobody can stand in for them. Stages and backup approvers aren't there either. We looked in the panel and in the space settings.

Automation can start an approval but can't react to one

In the automation flow builder, a trigger search for "approv" returned "No triggers match your search." The same search under actions found one Confluence action, Start document approval.

CONFCLOUD-85157 (3 votes) says the same thing from Atlassian's side: "there is no dedicated Confluence Automation trigger that fires when a page approval status changes." It adds that the Page status changed trigger "does not detect Confluence Approval lifecycle events." So a rule like "when a policy is approved, copy it to the published space" can't be built on approvals yet.

Marketplace apps can't read approval data

CONFCLOUD-85194 (5 votes) says "No approval data is available via any public Confluence REST API (v1 or v2)." So a Marketplace app or your own REST script can't see who approved a page. Atlassian's own tools are the exception. Per the September update in the same announcement, its MCP server (the connector AI assistants use to reach Atlassian), the Teamwork Graph CLI and Rovo can start and track approvals. Those weren't part of our run.

Standard plans don't get it

During the beta it's Premium and Enterprise. When people asked about Standard, the team answered "We hear you on Standard," with no date.

Check whether these gaps have closed

The three tickets are public, so you can check them yourself before you plan around a gap. This loop asks Atlassian's public Jira for each ticket's status and vote count (you need curl and jq):

for k in CONFCLOUD-85363 CONFCLOUD-85157 CONFCLOUD-85194; do curl -s "https://jira.atlassian.com/rest/api/2/issue/$k?fields=status,votes" \ | jq -r '"\(.key) \(.fields.status.name) votes=\(.fields.votes.votes)"' done 

You should see one line per ticket. On 5 November 2026 it printed:

CONFCLOUD-85363 Gathering Interest votes=12 CONFCLOUD-85157 Gathering Interest votes=3 CONFCLOUD-85194 Gathering Interest votes=5 

If a ticket reads anything other than Gathering Interest when you run it, that gap may have closed, so check the ticket before you buy anything.

Step 5 — On Standard, build Confluence approval automation with page status

If you're on Standard, content status plus Confluence Automation is what you've got. A status looks a lot like an approval step. In practice it works like a label you stick on the page.

Statuses are "a combination of a colored indicator (purple, blue, red, yellow, or green) and a label (up to 20 characters)." The defaults are Rough draft, In progress and Ready for review, and a space can have "up to five."

The catch is one line in the content status doc: "anyone with edit permissions can set the content status." Nothing in that doc says a status restricts anything.

Verified is the exception. Atlassian limits it to "page owners or space/site admins," which still lets an author verify their own page.

In August 2025 Atlassian's Customer Success team published a recipe that changes an unauthorised Verified back, Restrict who can Approve Pages in Confluence. Here it is as steps:

1. In Space settings → Automation, select Create flow, then Create from scratch. The flow builder opens (the screen says flow where the recipe says rule).
2. Add the trigger Page status changed and set the status to Verified. The trigger needs content statuses switched on in the space.
3. Add a User condition, choose User who triggered the event, set it to is not in group, and pick your approvers group.
4. Add the action Change page status and set it to Ready for review.
5. Turn the rule on and give it a name (the recipe's button is Turn on rule; the flow builder may say flow). From now on, a Verified set by someone outside the group should flip back to Ready for review.

Optional: add a Restrict page action to lock edits once a page is approved. The actions doc says it changes "a page's view and edit permissions."

We opened the Page status changed trigger in the flow builder on our site but didn't save a rule. So try yours on a scratch page before you trust it. Two old bug reports on this trigger, CONFCLOUD-79255 and AUTO-872, were closed as timed out.

It has gaps, though. Even when it works, the page says Verified for a moment before the rule changes it back. A status also belongs to the page, so it doesn't change when the text does. A vendor's reply in a 2026 Community thread put it as "the status sits on the page itself, not on a specific version." And one status change is one person, so "two of these three" means counting you'd build yourself.

So is it good enough? I think it's fine for a team wiki where "approved" means "my lead looked at it." For a policy an auditor will ask about, I wouldn't lean on it.

Step 6 — Create a multi-approver Confluence approval workflow with any-one, all or minimum-N approvers

Sentinel Vault is our own app, so read this part knowing that. Sentinel Vault is a Forge app (Forge is Atlassian's platform for cloud apps) that Mihai Perdum built at LeanZero. 8.26.0 is the version on the Marketplace today. We ran the steps below on our test site with the development build, which also reports 8.26.0.

Turn the workflow on and pick the approvers

The workflow is off in each space until a space admin turns it on. It's called Document Approval and has four states: Draft, In Review, Approved and Needs re-review.

1. Open the space and choose Sentinel Vault among the space's apps. Its space console opens.
2. On the Workflow tab, turn on Enable document workflow and select Save workflow settings. The workflow is now on for the space.
3. Select Edit the states, approvers and protection and switch on Require approval to reach Approved. Below it are Approvers, Approver groups and Decision rule.
4. Add approvers as people, groups or both, and pick a Decision rule from the table below.
5. Under Protecting Approved pages, pick what happens when someone else edits an Approved page: Move it back to an earlier state (the default) or Revert to the approved version, both explained in the next section. Set the re-review period there too (we used 180 days), then select Save workflow. You should see "Workflow and its settings saved."

Space admins can approve without being listed. That's on by default, and in a strict policy space you may want to switch it off. With "any one" their approval completes the request, and with "at least N" it counts toward N. The person who asked never counts on their own request.

Decide what happens when someone edits an approved page

This choice applies when someone who isn't an approver or a space admin edits an Approved page. The default is Move it back to an earlier state: their edit stays and the page goes back for a new review, to Draft unless you pick another state.

The stricter option is Revert to the approved version. Their edit is discarded and the approved version comes back as a new page version with the message "(Sentinel Vault reverted unapproved change to the approved version)." Their text stays in the page history.

A Forge app can't veto a Confluence save, so Sentinel Vault catches the edit after it's saved. It checks when Confluence sends the page event, when someone opens the page, and in an hourly sweep. Page events can arrive late: on 15 September 2026 we measured them reaching the app 9 to 10 minutes after the edit, on our test site, on one day. So if nobody opens the page, the unapproved text can sit there for minutes.

Atlassian says native Approvals with the publish gate on stop the publish itself (see Step 2), which is a real point in their favour.

Both choices depend on one site-wide Sentinel Vault setting, Protect Sealed Attachments in Page Body, which is on by default. Despite the name, it switches the whole page-body guard, and Approved-page enforcement runs on that guard. If a site admin turns it off, nothing is moved back or reverted. The Workflow tab and page banner then say Approved pages aren't protected.

Approve it and read the record

Sentinel Vault adds a ribbon to each page under workflow. It shows the page's state, and its state chip is the button you use to move the page between states. My work is the app's page listing each person's pending approvals.

To start, open the Sentinel Vault item in the page's byline and select Start workflow on this page. The page starts in Draft.

Next, use the state chip to move the page to In Review. Then use it again and choose Request approval → Approved. The ribbon shows 0 of 2. Elzi's My work page showed "1 waiting on you."

Each approver opens the request from the ribbon, can add a reason (it's optional) and selects Approve. After the last approval the ribbon reads Approved v1. Elzi approved with "Meal limit checked with Finance." Theo approved with "Booking rules match the travel desk contract."

Then Iris, who is neither an approver nor an admin, edited the page. About 30 seconds after she published, the ribbon read Draft. We didn't record which check caught it; opening the page runs one. The Activity tab had the whole story.

A space admin can filter that tab and export it as CSV. History is kept unless a site admin turns on Delete old history. Then entries older than 730 days (the default) are deleted weekly.

Approved pages also get a re-review date: 150 days by default, and we set 180. The hourly sweep moves a page to Needs re-review at the first run after that date, usually within the hour. On sites with more than 2,000 pages under workflow it can take longer. Native approval expiration covers the same need, so pick whichever tool you're already on.

You can watch the whole flow in Mihai's two-minute video, Confluence Page Approval: Draft to Approved, Enforced.

Optional: ask approvers for an authenticator code

Require a signed decision makes each approver type the 6-digit code from their authenticator app when they approve or deny. They set it up once on My work, under Your approval signature. Codes are single-use, and five wrong codes lock that person's signing for 15 minutes. We left it off in this run.

What it proves is that the approver had a device enrolled with the app. It's one factor, and it doesn't make a decision an electronic signature in the regulatory sense. 21 CFR 11.200 asks for "at least two distinct identification components," and we don't claim Part 11 or any other certification.

What Sentinel Vault doesn't do

It doesn't block the save. It doesn't read or write native Confluence Approvals, so pick one per space. Approval covers the page text. To hold a file, seal it (Sentinel Vault's lock for a single attachment); a sealed file on an Approved page stays sealed until the approval ends. There's a separate tutorial on locking attachments in Confluence Cloud. This run used "all approvers" and the move-back option. We didn't test Revert, "at least N," signed decisions, or Sentinel Vault and native Approvals on the same page. The listing says it's licensed under Apache 2.0 and its 10-user tier costs nothing.

Other apps cover approvals too. Appfire's Page Approval and Comala Document Approval, AppFox's Approvals for Confluence, Approval Path, Aura Apps' AURA Workflow & Approval, Approval Seal and Sealed are all on the Marketplace (checked 5 November 2026). I haven't tried them, so I won't rank them.

Check it worked on a test page

Before you roll a route out to a real space, run it once on a scratch page with two other accounts. This is what you should see:

If it didn't work

Here are the messages you're most likely to hit, with the fix for each.

What you have now, and which route to use

[[takeaways]]

• A space where pages go to named approvers, natively on Premium or Enterprise, with the approval history in the page's activity log.
• The limits, checked on screen: every approver must approve, approvers are people only, up to 10 per request and 5 required per space, and no approval trigger in automation.
• A Standard-plan fallback: page status plus the automation rule that changes an unauthorised Verified back.
• A multi-approver workflow in Sentinel Vault with a decision rule, a move-back on unapproved edits and an Activity log you can export.

The parts our run didn't reach are named where they apply: the publish gate in Step 2, other editors in Step 4, the automation rule in Step 5 and the Sentinel Vault options in Step 6. Try those on a scratch space before you rely on them.

If I were picking today, I'd probably go like this. On Premium or Enterprise, with a fixed group of people who will all sign, use native Approvals with Required approvers and the publish gate on, with live docs off in that space. The gate is the one setting our run didn't reach (Step 2), so that part rests on Atlassian's description. On Standard, where approval means "my lead looked at it," page status plus the automation recipe in Step 5 will do. And if you need any one of three, two of three, group approvers, or a code on each sign-off, you'll need an app. Sentinel Vault is ours, and the product page has the details.

If you run approvals in Confluence today, I'd love to hear which of these you picked and why. And if change requests in Jira are your other headache, our Jira CAB approval tutorial covers that side.

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.