What to expect with the Confluence roles Beta + checking in on the EAP experience

[#1]

Hi folks,

You’ve now had the roles experience in Confluence for anywhere from a few weeks to a few months and we’d love to hear from you about how it’s going!

Questions we're particularly curious about

• What do you like about using roles for managing access?

• What challenges have you had in adjusting to the new role-based access model?

• What has been your process for updating access from permissions to roles across your site?

• Have you encountered any unexpected challenges when moving your spaces over?

• How many custom roles do you think you would need to completely move off of custom access?

  • We're planning to enforce a custom role limit, so we want to understand how many custom roles you expect to need 

• What do you wish we’d build next?

Please reply in the comments or book time with me to share your feedback!

What’s coming next from roles

Our next milestone will be our Beta release (coming your way in June) that will include a lot of new functionality, including:

• Custom roles to support access needs beyond the four default roles provided.

• “Add people to all spaces” flow supports bulk role updates. Assign a user or a group a role across all spaces in your site.

• New permissions & updated permission descriptions. We’re adding a few new permissions to allow for further fine-tuning and updating the permission descriptions to be more intuitive. New permissions include:

  • Export individual content items, split out from the existing View content permission

  • Create and edit content is now two separate permissions - Create content and Edit content

  • Create and edit blogs is also now two separate permissions - Create blogs and Edit blogs

We’ll share more details on what to expect with the Beta experience updates in the coming weeks.

Best,
Marie & the Confluence Permissions Team

[Sara Tucker]

I'm getting a message that "Your actions are limited due to your space access level" when trying to delete a user. I have confirmed I am a space admin. Is that a bug or is there something I am doing wrong/user error? 

[Jeremias Renner]

@Marie Casabonne hey thanks for the feedback prompt here. We are overall making really good experiences with the RBAC. It seems to be really intuitive for admins. We have not enforced it, like forcing all admins to update their space permissions to the four roles. I don't think we need more granular (custom) roles though, as long as custom access is still possible, this will cover the 1% edge cases. 

In the beginning we had a bug that some users could not be added. You might remember that you set up a call with a developer where we figured out it had to do something with the "old" or "very old" types of users, but it was resolved very quickly and probably isn't even an issue anymore.

One thing I have been wondering: Wouldn't it be nice to have a User Class called "All internal Confluence Users?" This would simplify access management a lot. It would be enough just to rely on the "managed" flag from the admin console. We work a lot with external users, and depending on the space, content may be too sensible to share it with "all confluence users". Are there any plans? Maybe it would be nice to let me as org admin define a custom "user class" for this?

[Marie Casabonne]

Hey @Sara Tucker - I'm so sorry for missing your note here! Are you still seeing this bug? I'll follow-up via email to get more details so we can investigate.

[Marie Casabonne]

Hey @Jeremias Renner , thanks so much for your feedback! I'm glad roles are intuitive for the team, and that the shift to using them has gone well. 

We do plan to eventually remove custom access and force all users, groups, etc. that have access in a space to be on a role. That won't be until 6+ months after roles GA's. With custom roles, you'll be able to create a role to meet the permissions needs of your users with custom access, and move those folks over to roles, too. 

I'm curious to learn more about how you work with external users. Are they licensed users, guests, or are you utilizing anonymous access? How would you envision an admin-managed user class differing from an admin-managed group or team?

[Jeremias Renner]

Hi @Marie Casabonne thanks for the heads up on custom roles and custom access. In this case we might use custom roles, but tbh I don't know yet which ones these would be. Probably I'll strongly prefer and encourage using the built-in ones. If it will become necessary to migrate, it would be great to have some admin overview or interface even to migrate the custom accesses to a certain role in bulk or so. Or automatically convert them to custom roles and then maybe merge them with other custom roles or the built in roles in bulk. In our case, it would probably still be possible to look at every space with the admins / owners, but in my former job i.e. I've managed a much larger site where this would have been next to impossible. Just my thoughts here.

External users: I am talking about licensed external users. I think guests and anonymously accessing users (which we both also have) are very easy to shut out because they need to be invited in explicitly. In atlassian terms, the easiest ways to tell internal and external apart (although all are licensed) would be their email domains or their status as managed vs. unmanaged. I'd imagine a custom user class in a way that I could define the class name and a few rules which users should be included, for instance select email domains, or select managed / unmanaged. This would differ a lot from groups because those classes are built automatically in Atlassian Administration. Groups can't be built dynamically, at least not in atlassian. I am trying to set up something similar with the help of Entra ID now, where groups come from the identity provider. This is not very handy for external users though, as they are not managed by my organization and therefore can't be provisioned automatically. A custom user class would achieve the same thing quite easily. Even if the user class could only be based on a group (1:1), I could make use of it, because while now I can provide a group that is called SG-O-All-Internal_Users that is synced from entra, it is not very intuitive. If I could make this a user class, I could let it show up in the spaces' access administration without the need to give it default access (like I would have to do with a group to let it even show up there) and give it a telling name. Here's a mock-up:

Now (need to give access to the (cryptic) group to have it show up as default


Suggestion (no need to give it default access, but show it as an option, readable)