Feedback request: Shape the future of Confluence Permissions!

[dhur]

Hello Confluence Cloud Admins!

We’re Deborah and Nidhi, Product Managers on the Confluence Permissions team. We’re exploring comprehensive permissions improvements to relieve user frictions and simplify workflows. We need your feedback to help us define and prioritise permissions improvements.

Help shape the future of Confluence Permissions

How do you use permissions today? Are there any thorny problems related to permissions that impede collaboration with your team? Any common gaps in permissions you want to surface?

Let us know your thoughts!

We’re collecting feedback in a few different forms:

• Reply to this community post: We will include these in our post-research analysis and findings.

• Volunteer for a user interview: Express your interest in participating in a 45-min user interview at https://www.userinterviews.com/projects/kGu0WGRymg/apply

Thank you,
Deborah and Nidhi

[Keith Sottung]

Site admin must be able to assign a Space Admin rights to add and remove users from a User Group.  

[Howard Phillips]

Exactly!

[Keith Sottung]

Site Admins should be able define Roles.  The Roles serve as User Group Index.  For example, if I grant permission to an employee (role), then they are automatically added to a specific set of user groups.  In this use case, a majority of the "employee" related space's permissions are managed using User Groups.  

[Howard Phillips]

Actually roll out the changes to user management that Atlassian announced on 11th Jan 2021 to existing customers. See this post: Centralized user management for Atlassian cloud products. Then I'd be able to make use of the Confluence Administrator role.

[Howard Phillips]

Should be able to (recursively) synchronise child page restrictions with the parent page in a single step. I.e. if I set a write permission restriction, I should be able to automatically apply the same restriction to all its children (and their children, all the way down).

[Howard Phillips]

It would be nice if page restrictions could be set to explicitly NOT allow view or edit access to a user or group. At the moment, if you want to prevent a user/group from accessing a set of pages, you actually have to set explicit allowed permissions for all the other users/groups, rather than just saying the one you want to prevent doesn't have permission.

[Keith Sottung]

There should be a "check email is valid feature." Currently, before I burn a license, I email a prospective member and request they read it and reply back.

What I like about this is that I get a chance to explain a few things to the prospective member and prompt them to take the Confluence Basic online course. Often many users join confluence and no one had a chance to talk to them about it and where they can get information about it prior to joining, this allows for me the "first contact". 

To me, if there was a built in process to validate the email account via a selection of user defined welcome templates it would go a long way to make sure the joining member correctly join (e.g. by an identity provider) but at the same time are provide ways to learn more about confluence.  

I've attached a copy of the email I send to users to prior to burning a license.

[Steven Haworth]

For software development, most spaces are linked to a Jira project - and in Jira we have roles, permission trees, etc.

It would be very helpful to be able to administer those permissions in a single place when the space is linked to the project.

Today, we mostly use groups, but the problem there is (sadly) groups can only be managed by full system admins, which becomes a bottleneck.  It would be FAR better for space/project admins to manage their own groups.

[Tracy Stimac]

When dealing with eDiscovery needs, confluence admins need to be able to restrict access to read only even from the space admins (especially since a space admin can make anyone else a space admin) until the legal hold is removed.

[Stavros_Rougas_EasyApps]

No clear overview. Convoluted.

Have groups, individuals, guests, anonymous... great to have options but in cloud it's like copied server which has so much legacy code/UI rather than a fresh cloud approach see in other tools.

I have thought a lot about permission design as we have done something unique for our app Easy Toolbox, a suite of bulk editing features for Confluence. System admins can enable/disable by user, group, feature, space. I believe the UI is good. @dhur I suggestion you evaluate it and see for yourself.

The point is that everything is complex. But good UI makes the complex seem manageable for users. Right now you need a PhD in permission management it can feel like, and what happens is that the permissions get done but at times in a messy way that can make it hard to manager when a new admin takes over.