After the roles rollout, two kinds of rows slip through most Confluence access reviews

[#1]

Atlassian is rolling role-based access out to every Confluence Cloud site — per their GA announcement https://community.atlassian.com/forums/Confluence-articles/Confluence-Role-Based-Access-Control-RBAC-GA-Coming-Soon/ba-p/3248592 starting early July 2026 and finishing by the end of September, and in their own words, "when roles roll out to your site, no one's access changes". The second fact that frames everything below comes from the official transition guide https://support.atlassian.com/confluence-cloud/docs/custom-access-and-how-to-transition-to-roles/ existing grants are not translated into roles — "as soon as the role experience lands on your site, all users and groups access will display with 'Custom access'".

That second fact is where access reviews quietly break, because "Custom access" is not a permission level. It means no role has been assigned yet: the underlying permissions are intact, they just aren't described by a role name. Two rows can both read Custom access and mean completely different things — one group that can only view, another that can edit and delete. If your review works by reading role names (Viewer, Contributor, Admin), Custom access rows are exactly the ones you skim past — and right after the rollout, that can be every row you have. Atlassian's transition guide is direct about where this should end up: "we recommend against using custom access because eventually, all custom access accounts will have to switch to a role". In other words, each of those rows is a decision someone will eventually have to make — reviewing them early, while the list is short, is cheaper than reviewing them after a year of accumulation.

The second kind of row people skip: integrations. Roles are held by principals, not just people — and apps are principals too. On a brand-new Cloud site we set up this week, the very first space we audited listed four integrations holding space roles, several of them with the Admin role, before any human had deliberately configured anything. To be clear, those were all standard, legitimate integrations doing their job — the point is not that apps are dangerous. The point is that a review that reads only people and groups can't tell you which apps hold Admin, and "we didn't look" is not the same as "there was nothing to see". Whatever method or tooling you use, put app principals inside the scope, not outside it.

What a useful review looks like after the rollout, regardless of tooling: treat every Custom access row as unknown until someone has opened it and written down what it actually allows; migrate those rows to named roles deliberately rather than letting them accumulate; include apps and integrations in the same sweep as people; and keep an exportable record, because "we reviewed it" without evidence doesn't survive an auditor. For per-page visibility there's also an open suggestion worth voting on — CONFCLOUD-70430 https://jira.atlassian.com/browse/CONFCLOUD-70430 proposes a "people who can view this page" list for Cloud, and at the time of writing it sits in Gathering Interest.

Full disclosure: I'm one of the people behind Prometheus Agency, the company that builds Access Lens, so read the next paragraph with that in mind. Everything above works with no app at all, and more than one Marketplace app automates parts of it.

We built ours because doing that sweep by hand across every space doesn't scale: classic permissions and role assignments merged into one table, integrations labelled as apps rather than people, over-broad access flagged, and a CSV export for auditors. It runs entirely on Atlassian-hosted infrastructure.

https://marketplace.atlassian.com/apps/690945338/access-lens-permissions-audit-for-confluence

Happy to answer permissions questions in the comments either way — the review habits are the part I'd keep even if you never install anything.