Roles instead of tables: Atlassian simplifies authorization management in Confluence
Who doesn't know it: You just want to quickly give someone access to a space — and end up in an endless table full of checkmarks, groups, and cryptic permissions.
With the new role-based access (RBAC) in Confluence, Atlassian introduces a much simpler, clearer and scalable way to manage permissions. Sounds too good to be true? Then welcome to the new world of Confluence Roles.
Easy access - finally clear
With the new role model, authorization management in Confluence has never been easier. Instead of clicking through individual permissions, you simply select a role in the future - that's it.
There are four standard roles to choose from:
- Admin — manages everything in space → Ideal for IT teams or space owners.
- Manager — cares about content and people, but not space settings. → Perfect for project or team leads.
- Collaborator — creates and edits content.
- Viewer — can view and comment on content
And if you need it more individually, you can even define your own roles.
➡️ Learn more about Confluence roles
Standardised, consistent and comprehensible
Anyone who has worked with authorization tables up to now knows that at some point, every space configuration is like an expert-level Sudoku. With roles, Atlassian is finally bringing structure to this chaos.
Each role is clearly defined, functions the same in all spaces and thus ensures consistency and traceability. Changes or sources of error can be found more quickly - and even during auditing, it is immediately apparent who has access to what.
If someone is allowed to do too much or too little, Confluence now offers easy ways to view and adjust all sources of a user's access.
➡️ Learn more about troubleshooting access issues
And no, it's not the same as in Jira 😉
The term “roles” quickly creates confusion, as it has been around in Jira for a long time.
But: Confluence roles have a completely different technical structure.
In Jira, roles are more organizational placeholders - they define who can take on specific tasks in a project.
In Confluence, on the other hand, roles directly control space permissions: i.e. who can read, edit, archive, or administer content.
In short:
- Jira roles → organizational project roles
- Confluence roles → technical space permissions
Both are called the same but mean something completely different.
Quick start with standard accesses
With the new standard accesses for new spaces, admins save additional time.
Instead of setting all permissions individually for each new space, a standard configuration can be defined — including predefined roles for specific groups or user classes.
New spaces automatically adopt these settings, but can be individually adjusted at any time.
➡️ Learn more about standard accesses
User Classes: More overview, less group chaos
In larger organizations, group structures like to grow infinitely.
With user classes, Confluence also makes life easier for administrators here.
Instead of juggling tens of groups, permissions can now be assigned directly to higher-level classes, such as:
- All Confluence users — all users with access to Confluence
- All Confluence admins — all users with admin rights
For example, it can be ensured that all employees receive reading rights (viewers), while admins automatically have more comprehensive access rights.
What are the limits of the new role model?
As practical and clear as the new role model in Confluence is, it does not have any restrictions. There are currently still limits of 10 for custom roles - i.e. for individually created roles. Although these can be defined flexibly, they are not automatically migrated to other instances. So anyone who moves data or spaces between Confluence environments (from sandbox to production, for example) must manually recreate custom roles. Space-specific role assignments are also lost during a migration and are displayed as “Custom Access.”
Migration & compatibility - please be careful before clicking
The new role model is based on the Role-Based Access Control (RBAC) system.
Important to know:
Once an instance is converted to RBAC, this step cannot be undone.
That is why the golden rule applies:
→ First try it out on a test instance before the production environment is converted!
In this way, potential effects on groups, automations and individual authorizations can be safely assessed before the change is final.
When migrating between instances, the following also applies:
→ Only RBAC to RBAC migrations are supported. Old authorization tables and individual roles may have to be created manually.
Conclusion: A big step for admins - a small click for you, but not for everyone
With the new role model, Atlassian is creating what many have wanted for years: a clear, understandable authorization system without endless tables.
Admins get more control, space owners get a better overview and everyone else gets more time for the really important tasks.
However, the role-based authorization system (RBAC) is not suitable for every organization. Atlassian himself says that it is more for new organizations and customers with smaller and simpler organizational structures.
Consider testing it on a secure, non-productive instance (such as a sandbox) first if: Your organization is large or complex, your instance has a large number of areas, your plan is to assign custom roles to guests (not yet supported), or you're planning to migrate in the near future, then the role model wouldn't be right for you.
Our tip
Would you like to check whether the new role model is already available for your Confluence instance or how you can best prepare for the transition?
We're happy to support you - from analyzing your existing permissions to secure migration.
👉 Arrange a non-binding consultation now and simplify Confluence access!
.webp)
