Approvals in Confluence, now on Open Beta

[Cassandra Rinker]

From testing and what I've gathered in these comments, this feature only applies to new pages, and there's no way to apply this approval gate to edits on existing pages? If so, this doesn't help us with maintenance through the entire knowledge lifecycle. Our use case: Our customer-facing pages have to meet certain guidelines, and we want to allow SMEs to edit customer-facing content but have this approval layer in between their edits going live. We rarely have SMEs writing pages from scratch. 

[Linda Wu]

@Josue Paniagua Varela - thanks for sharing your use case on due date recurring reminder intervals! I can see why a single reminder before the due date may not be enough for time-sensitive reviews and shared this as product feedback for the team.

@Jason Krewson - today approvals are available on Confluence Premium and Enterprise only. We don’t have an update to share on Standard availability, but the team is tracking that feedback from customers in this thread. If that changes, the support documentation and release notes will be updated first.

@Cassandra Rinker - you're correct in that “require approval before publishing” gate currently applies to new pages, not edits to an already published page. We’ve heard similar lifecycle and compliance feedback from other teams in the beta, especially for controlled knowledge that needs review before updates go live. Thanks for calling out the SME-maintenance use case; we are planning to extend the publishing gate to subsequent edits beyond new pages' first drafts. This will be available in an upcoming release - stay tuned!

[Linda Wu]

@Shawn Stevens - thank you for the detailed write-up. Feedback submitted through the in-product mechanism reaches the same team, so no worries either way! To address your feedback:

1. Rovo Chat publishing - I've logged this issue with the team. We will look into creating a more seamless experience with Rovo Chat. A publish that cannot proceed should tell you an approval is required, rather than failing with a generic reload error.

2. Publishing elsewhere and moving the page - thanks for flagging this. Approval is currently evaluated at the point of publish, so a page that has already been published isn't re-evaluated when it's moved into a space that requires approval. I've raised this issue with the dev team as well.

3. Requiring one of two approvers - yes currently we are requiring a unanimous approval. All named approvers must approve. A quorum option has been raised by others in this thread as well, and it's logged with the product team.

4. The second approver not being notified - as you mentioned, it's worth checking that person's personal notification settings first. If notifications are enabled for them and the email still doesn't arrive, let me know and we'll look into it.

On the automation route: if you have some specific use cases you want to share, we can look into it further. We have planned to add some automation triggers and actions that may be helpful. I'll also tag @Cadence Hsu as the Product Manager who is leading this effort.

[Farah Idayu Othman]

Hi Alli Shea,

It's awesome to have this new Confluence feature!

I have one piece of feedback:

It would be worth clarifying how Approvals interacts with page restrictions. Specifically, approvers without edit access should still be able to submit their approval response when a page is under review. This feels like an important gap to address to ensure the approval flow isn't blocked by existing permission settings.

[Farah Idayu Othman]

Hi @Alli Shea ,

I have one question about expiry and re-approval.

When an approval expires and a content owner triggers a re-approval, does the page automatically revert to "In Review" status, or does someone need to initiate it again manually?

Thank you!

[David Yu]

We are also waiting for support for approvals on Page Edits for this to be useful.

[Francisco Loureiro]

Disclosure up front: I build an app in this space, currently pending Marketplace approval, so read this as context rather than a recommendation.

@__ Jimi Wikman on your ISO question, I don't think the Trust Center answers it for the reason you gave. It covers Atlassian's own certifications, not whether the feature satisfies a clause in someone else's QMS. So I spent an evening testing the beta on a Premium site against the three things an auditor actually asks: who signed off, whether the copy people are reading is still the approved one, and when it was last reviewed.

Your live docs point is the sharpest one, and it holds. Approvals apply to pages only, not live docs and not blogs. So the conversion route you're worried about sits outside the feature entirely.

On whether the live copy is still the approved one: a single editor can open an approved page with no lock. On publish you get one dialog, "Proceed with replacing approved content?", and a single Confirm. Confirm, and the new content is live and the Approved badge is cleared. It won't lie to you, but one person replaces an approved document on their own, with no second pair of eyes. @Linda Wu described the compliant path in July: send the draft through its own approval cycle and publishing preserves the approved state. So native offers that path without requiring it. Worth adding that no app can close this either. Linda confirmed on 13 July that publish-gate access isn't available to app partners, so any enforcement outside the native feature has to go through page restrictions.

On review cycles: there are three fixed states, and approval is unanimous across every named approver, up to ten. What there isn't is a scheduled re-review. The due date is a reminder for that round, as the field's own help text says. Most QMS run documents on a periodic review cycle, and that has to live outside Confluence today.

On the record itself: the approvals panel does keep an activity log of decisions. What I'd flag is that page version history keeps nothing. After approving and then overwriting, the history showed two content versions and no indication that anything was ever approved or that an approval was cleared. If your auditor works from version history, that's the gap to plan around.

The other thing to know before planning around any of this: approvals are Premium and Enterprise only. On Standard the feature doesn't exist, and as of 20 August there was no update on whether it will.

[Linda Wu]

@Farah Idayu Othman - thanks for testing the feature and providing your input. For your first question regarding content restrictions, approvers need edit access on the page to respond to an approval, so if a page restriction removes edit access the approval flow can get blocked until that access is granted. We are currently exploring ways to make this flow more intuitive.

As for your expiry date question, it depends on the approval-expiration setup in the space. If automatic restart is configured, Confluence will create a new approval cycle when one expires; otherwise a new approval needs to be started manually. Expiry dates will be available in an upcoming release and the configuration options will be available under the space settings. For now, the due dates that you see are notifications-driven only.

[Lars Maehlmann]

Thank you to the Confluence team for building this! Native approvals inside the page.

One question about how multi-approver requests are completed: when I add several approvers to a page (or several enforced approvers at the space level), can I control the completion logic? Specifically, can I choose between “any one approver is enough” and “all approvers must sign off”

Right now it looks like every named approver is simply notified and responds individually, with no quorum or mode setting. For our use cases, both patterns come up: legal/compliance pages where every reviewer must explicitly approve, versus a pool of eligible reviewers where a single approval should be sufficient. Is mode/quorum control on the roadmap, or is there a recommended way to model “any one of these people” today?

Thanks again!

[Kovalainen Arto]

I tried this feature, and I don’t think the current workflow fits how approvals are typically managed.

In my view, approvals should be more closely tied to actual page statuses. For example, if a page has the following statuses:

• Draft

• Review

• Active

Then approval should happen during the Review phase, and only designated approvers should be able to move the page from Review to Active.

[Linda Wu]

@Lars Maehlmann - glad to hear the excitement about the feature! Yes, right now approvals use an all-approvers model which fits your legal/compliance use case: a request becomes Approved only after every named approver approves. For your second use case, there isn’t yet a per-request “any one” or quorum setting. For an “any one of this group” workflow, the practical workaround is to select a single reviewer outside the request. We don’t have a published timeline for quorum controls, but this is valuable feedback that I've forwarded to the product team. 

@Kovalainen Arto - thanks for the feedback. Native approvals use new approvals-specific built-in review states such as In review, Changes requested, and Approved; custom content statuses remain informational rather than role-gated workflow steps.

However, it sounds like there are automation rules that your team can set up to execute the behavior that you are describing. You can add automation rules to trigger approvals upon page status change. In addition, we'll be adding some automation capabilities in the upcoming releases that will add approval status change triggers as well at which point you could set up an automation rule to change a page status when the approval status also changes. I'll cc our PM leading the automation effort @Cadence Hsu here.

[Robin]

Would be great that the "Require approval before publishing" is not just for new pages, but also for edits.
At the moment you can edit, confirm a warning and publish a page. this page is then publicly visable (without the small approval check icon). But a normal viewer will not check that icon.

So for us it would be great:

- that just approved pages are displayed in spaces where the flag is on.

or

- prevent publish an edit and give just a button to start an approval.

But all in all we like that new feature!