Confluence RBAC rollout: check your fallback role before the transition window closes

[#1]

Roles are landing on Confluence Cloud sites right now, and most of the coverage so far explains what role-based access control is. That part is easy. Here is the part I have not seen written down anywhere, and it is the part that will actually bite: the transition completes whether or not you participate, and a single setting decides what happens to everyone you did not get around to. That setting defaults to Collaborator.

If you read nothing else, read the fallback role section below.

Scope note: this applies to Confluence Cloud (Standard, Premium and Enterprise). Confluence Data Center keeps its existing permissions model and is not part of this change. Everything below was verified against Atlassian's support documentation on 28 July 2026, plus the GA announcement on this Community. Where the docs do not state something, I say so rather than guess.

Updated 30 July:

Two corrections and additions from the comments. The Roles central menu placement varies by site: some sites show it under Permissions, matching the documentation (thanks @Daniel Klein for the screenshot), while mine shows it under Security. Check both. And per Daniel's report, the audit tools (permissions combinations CSV and user access audit) are available even on sites still in pre-roles mode, so you can size the job and plan your role mapping before the transition reaches you.

What actually changed on your site

Per Atlassian's GA announcement, roles began rolling out to all Confluence Cloud sites starting the week of 6 July 2026, and the rollout is still in progress as I write this, expected to reach every site by around the end of September. If you go looking for any of the screens below and cannot find them, you have not done anything wrong, roles simply have not reached your site yet. Bookmark the checklist and check again in a few weeks. Everything here applies from the day it lands. 

Updated 30 July:

One exception worth knowing, from the comments: even on sites still in pre-roles mode, the two audit tools (the permissions combinations CSV and the user access audit) can already be available, so the planning work in step 1 below can start before the transition reaches you.

There are three space access modes a site can be in:

• Pre roles. The classic experience: access is managed with individual permission checkboxes.
• Roles transition. Both models work at once. Individual permissions AND roles.
• Roles only. Roles are the only way to manage space access. All new Confluence sites are created this way.

When roles arrive on an existing site, you land in roles transition mode, and nobody's access changes. Atlassian is explicit about this: both models are supported temporarily so that no user has more or fewer permissions than they had before.

My own site is in roles transition mode today. There is no label anywhere announcing which mode you are in, so here is how to tell: open any space, go to the access or users screen, and look at the list. If some entries show a role and others show "Custom access", both models are live and you are in transition. If everything has a role and there is no way to set individual permissions, you are already roles-only. The other tell is Roles central itself: once a site goes roles-only, Atlassian's documentation says the transition tooling and permissions exports disappear from it entirely.

The four default roles are Admin, Manager, Collaborator, Viewer. Manager is the genuinely new one, sitting between full space admin and content editing, and Atlassian created new granular permissions specifically to make it possible.

The naming trap that will cost someone an afternoon

On the day roles land, every user and group on your site displays as having "Custom access".

That does not mean they have a custom role. It means no role has been assigned yet. Atlassian's own documentation calls this out because the two terms are one word apart and mean opposite things: custom access is the absence of a role, a custom role is a role you built yourself.

Everyone showing "Custom access" is not a problem to fix urgently. It is the system holding your existing permission configuration exactly as it was, in the new model's display. But every configuration left on custom access is what Atlassian calls transition debt, and it is the debt the fallback role eventually settles for you.

What that looked like on our site: we came to Cloud from Confluence Server, and the permissions arrived configured exactly as they had been on Server, sprawl and all. When roles landed, every one of those configurations showed up as Custom access. We have been converting them selectively since, mostly to Admin and Viewer. The ones nobody gets around to converting are precisely the ones the fallback role decides for you.

The fallback role: the setting nobody is talking about

Roles central lays the transition out in four steps, and step 3 is the one to read twice. It is called "Prepare to only use roles", and it asks you to choose a fallback role. The product's own description: remaining custom access will be assigned this role when you move to role-based access only.

On my site, the role already selected was Collaborator. Not chosen by me. Selected by default.

Confluence is equally clear in the step 4 panel: any custom access you do not convert using the transition tools or the roles APIs will map to your fallback role selection when you move to role-based access only. And Atlassian's documentation goes further, stating that if you have not fully transitioned by the end of your transition window, Confluence will automatically convert remaining custom access to your configured fallback role.

So there are two ways the fallback role gets used: when you deliberately enforce roles-only, and automatically at the end of the window if you never get there. One of those requires you to do nothing at all.

Sit with what Collaborator means on a site where nobody touched that setting. In Atlassian's own guidance, Collaborator is the role you pick when you want someone to edit content but not much more. A view-only audience group could gain edit rights. A team that had been running a space at manager level could lose the ability to manage access. Nothing is deleted and nothing breaks loudly, which is exactly what makes it worth two minutes now rather than an incident review later.

Here is why that matters in a real configuration. We use the default roles as they come: Collaborator for the people who write and comment, Viewer for the people who read and comment. The practical gap between those two is the ability to create and edit content. So if a group we treat as read-and-comment were still sitting on custom access when the fallback applied, they would not quietly stay as they are. They would be able to write.

To set it: Confluence administration, then Settings, then Security, then Roles central, then step 3, Choose a fallback role. It sits under Security, not Permissions, whatever the documentation tells you. More on that below.

One thing I could not find anywhere, and I looked: no end date for the transition window is shown in Roles central, and none is published in the documentation I read. The product frames the fallback as applying when you enforce roles-only. The docs say it also applies automatically at the end of the window. Neither tells you when that window closes. Do not assume you have until the end of the September rollout period.

Roles central: the four steps, as the product presents them

Roles central (Confluence administration, then Settings, then Security, then Roles central) walks you through the whole transition in four numbered steps. Worth following in order, because step 4 stays out of reach until the earlier ones are done.

Step 1: Configure your roles and defaults. Four actions here, and the first two are the ones most people skip:

• View all permissions combinations, which downloads a CSV of every unique space permission combination on your site and how many users hold each. Run this before you plan anything. The number of distinct combinations is usually a surprise, and it is the number that decides how much work you are facing.
• Audit a user's access across all spaces, which reports which spaces a given user or group can reach and what access they have. This is the tool for answering "what will actually change for this team" before you change it.
• Create custom roles for the cases the four defaults miss.
• Update default access for new spaces, so spaces created from today use roles rather than adding to the pile.

Step 2: Bulk update access to roles. Two tools: assign by combination (give a role to everyone holding a specific permissions combination, across all spaces) and assign by user (give a role to a specific user or group across all spaces). Prefer assign by combination. It collapses hundreds of individual decisions into a handful, and the tool offers role recommendations where a combination exactly matches a role or is a near match. Review the impact preview before applying, every time. The recommendation is permission math, not knowledge of what your organisation intended. Every bulk change lands in the audit log.

Step 3: Prepare to only use roles. The fallback role, covered above. Choose it deliberately.

Step 4: Complete your transition to roles. The enforce switch, which turns on roles-only mode. Confluence tells you plainly to complete steps 1 to 3 first.

What changes when you go roles-only

Once you move to role-based access only:

• All access is managed exclusively through roles, including changes made through Automation and the API. If you have automation rules or scripts that set space permissions the old way, they need reviewing before this switch, not after.
• The transition tool, permissions data exports and the roles central transition view are no longer shown.
• You can still manage default and custom roles, configure system operations, and bulk update access by user.

One detail worth knowing, because it contradicts the "one-way door" framing you will see elsewhere: Atlassian's documentation states that future migrations into a roles-only site, including imports, restores and Data Center to Cloud migrations, may temporarily re-enable custom access in order to preserve migrated permissions. So the switch is designed to be final for day-to-day administration, but migration flows can reopen it. If you run migrations regularly, factor that in rather than being surprised by it.

The honest notes

The menu placement varies by site. On my site, Roles central sits under Security, alongside Security configuration, Global permissions, Space permissions and Analytics permissions, with no separate Permissions section at that level. On other sites, as @Daniel Klein  showed in the comments, it sits undePermissions, which is where the current documentation points. Both are live right now, presumably different admin navigation versions rolling out in parallel. So: check Security first, then Permissions, and look for the entries badged NEW.

No date is shown anywhere. Roles central tracks your progress but does not display when the transition window closes, and the documentation does not publish it either. If your site shows a date that mine does not, that is worth sharing in the comments.

Roles are not right for everyone yet. Atlassian's guidance is that the model suits simpler organisational structures best. If your site has a large number of spaces, complex delegated administration, or you are planning a migration soon, test the transition on a sandbox before touching production.

The checklist

• Open Roles central under Settings, then Security, not Permissions
• Check step 3 first. If the fallback role still reads Collaborator, that was chosen for you
• Download the permissions combinations CSV before planning anything
• Audit access for your two or three most sensitive groups before converting them
• Learn the difference between custom access (no role yet) and a custom role (one you built)
• Create custom roles for the cases the four defaults miss
• Update default access for new spaces so the pile stops growing
• Convert with assign by combination, reading the impact preview each time
• Review any Automation rule or API integration that sets space permissions before enforcing roles-only
• Do not assume a deadline you have not seen in your own Roles central

The transition itself is a genuine improvement. Fourteen checkboxes per user per space was never a system anyone could audit. But this is one of those platform changes where doing nothing is also a decision, and the fallback role is where that decision gets made. Make it on purpose.

Corrections and additions welcome, especially if something here does not match what you are seeing. If your site shows a transition window end date or a different fallback role default, say so in the comments and I will update the post.

Sources:

• What are Confluence's roles?
• Roles central and planning your transition
• Custom access and how to transition to roles
• Manage user roles and permissions in Confluence
• What to expect from roles when migrating Confluence data
• Coming soon: Role-based access control in Confluence GA (Community announcement)

[Chris Buzon]

This was a really, really good article.  Thank you for posting

[Becker_ Rene]

I liked you article. Thank you for your time and effort.

So far, I only knew that roles would become an additional, extra feature, not one to replace current permissions (and honestly, I did not see that part being advertised anywhere).

So do I understand correctly:

-> The current role system I have,set up via IdP groups (Cloud to Cloud), will be replaced and eventually removed in favor of Atlassian's roles?

---

[Daniel Klein]

Thanks Sami!

"Roles central" is placed under "Permissions" in our Confluence Cloud instance, like it should be according to the official documentations:

We are still in "pre roles" mode, however, we are already able to use the two transition tools View all permissions combinations and Audit a user's access across all spaces (can be found under https://<myinstance>.atlassian.net/wiki/admin/roles-hub ), so all (?) customers can plan their roles concept ahead of the transition phases.

Best Regards

Daniel

[Sami Shaik]

@Daniel Klein 

It's strange some users have it in the "Security" and some in the "Permissions".

[Sami Shaik]

@Becker_ Rene 

Good question, and it is really two questions, so let me split them.

Are the individual permissions eventually replaced? Yes. During the transition window both models run side by side, which is the "additional feature" impression you had, and honestly the announcements leaned on that framing. But the end state is roles only: at the end of the transition, remaining custom access converts to the fallback role, and after that, space access is managed exclusively through roles. So "additive" is the transition, not the destination.

Are your IdP groups replaced or removed? No, and this is the important part. Roles change what you attach to a group, not whether groups carry access. Today your IdP-synced groups hold a set of individual permission checkboxes per space. After the transition, those same groups hold a role instead. The groups stay, the sync from your identity provider keeps working, membership keeps flowing exactly as it does now. Roles are assigned to users and groups, and the bulk tools work at the group level.

Practically, for a setup like yours, the path looks like this: run View all permissions combinations to see what each IdP group actually carries today, then use Replace legacy permissions combinations with roles to map each combination to a default or custom role, and spot-check the result with Audit a user's access across all spaces for your most sensitive groups. Your IdP remains the source of truth for who is in the group; Confluence roles become the language for what the group can do.

One caveat to keep on the radar: once a site is roles-only, anything that sets space access through the API has to speak roles, not legacy permissions. If any part of your provisioning writes space permissions directly, that part needs reviewing before the switch. Group sync itself is unaffected.

[Sami Shaik]

@Daniel Klein 

This is exactly the kind of report I was hoping the comments would surface, thank you. So we now have two live sites disagreeing: yours shows Roles central under Permissions, matching the documentation, and mine shows it under Security with no Permissions section at that level at all. Which means the honest statement is not "the docs are wrong" but "the placement varies by site right now", presumably different admin navigation versions rolling out in parallel. I have updated the article to say exactly that, with credit to you.

Your second finding is even more useful: the audit tools being available in pre-roles mode means teams can size the job and plan their role mapping before the transition even reaches them. That changes the advice for everyone still waiting for the rollout, and it is in the update too.

[Sami Shaik]

@Chris Buzon 

Thank you Chris, glad it was useful. The comments are already making it better, which is the best outcome an article like this can have.

[Becker_ Rene]

@Sami Shaik : Thank you for taking the time to answer.

After I read this article I dived into the docs and ran some tests and your explanations really covered all gaps I had.

AND thank you very much pointing out the API-part. I already thought that I might need some adjustments and you confirmed it.

Do you know, if the role-API will become the only way to set permissions right away or if it will have a deprecation time like the other old endpoints we had over the years?

---

For others that are searching for the new endpoints:

Before:

{
"subject": {
"type": "group",
"identifier": "<ObjectID oder Groupname>"
},
"operation": {
"key": "read",
"target": "space"
},
"anonymousAccess": false
}

New:

{
"principalType": "GROUP",
"principalId": "<ObjectID>",
"roleId": "<roleId>"
}

(role id can be obtained in admin.atlassian.com or via a GET-Call)

GET /wiki/api/v2/roles

---

[Sami Shaik]

@Becker_ Rene 

Great question, and thank you for sharing the before/after payloads, that will save the next person real time.

Here is the current state as of today, checked against the developer changelog and API docs:

The new role APIs exist but are not final. The v2 Space Roles endpoints (create roles, set role assignments) are marked as part of the Role-Based Access Controls Beta, and in June Atlassian added a set of bulk migration endpoints (convert legacy permission grants to role assignments programmatically) which are explicitly labelled experimental while they validate the contract.

The old endpoints have no deprecation notice. As of today there is no changelog entry deprecating the legacy space permission endpoints. And Atlassian's track record on Confluence API deprecations is endpoint by endpoint, announced in the changelog, with a stated window that has historically been extended more than once. So a silent immediate replacement would be out of character; expect an announced window when it comes.

But the practical cutoff is not the API, it is your site. Once your site goes roles-only, space access on that site is managed through roles regardless of what the legacy endpoints technically still accept elsewhere. So the two things worth watching are the developer changelog for a formal deprecation notice, and your own site's transition state, because your integration's real deadline is the second one.

If you build against the new endpoints now, treat the experimental label seriously: fine for migration scripts you run and discard, risky for permanent tooling until they stabilise it.