Seeking input for Bulk Space Permissions

[dhur]

Hello Enterprise friends!

We're reaching out to the hive mind to get some concrete feedback on requirements for  Bulk Space Permissions functionality, a highly requested feature we are in the process of scoping and considering for nearer term roadmap. 

We'd love to hear from you about use cases in which bulk space permissions are needed:

• Task description (e.g. Add a new group to many spaces and configure permissions)
• When/Why 
  • Frequency 
  • Pain level on a scale of 1 to 7 (1 = annoying, 7=excruciating to the point it is not done)
  • (e.g. When a new team is formed due to company re-org: about 1-2 times a year, pain scales with how many teams are changed.)
  • (e.g. When new groups are created integrating Atlassian with our IDP: rare-hopefully just one time, pain is 7)
• Any other feedback you would like to share related to managing space permissions at scale.

We have not set a firm date for when this functionality would be coming, but will keep this group informed as we narrow in on requirements and finish scoping. Appreciate your help in advance!

Thank you,

Deborah (Confluence PM) & Kristen (Confluence Principal PM)

[Shawn Doyle - ReleaseTEAM]

off the top of my head:

Task description: Update permissions for multiple Confluence spaces to grant a new group access to view and edit content.

• When/Why: When a new department is formed or a cross-functional project requires collaboration across many spaces.
• Frequency: Occasional, as departments or project teams change.
• Pain level: 6 (time-consuming and prone to errors when done manually).

Task description: Restrict access to sensitive information across all spaces due to a security policy change.

• When/Why: In response to a security audit or policy update.
• Frequency: Periodic, as security requirements evolve.
• Pain level: 5 (essential but resource-intensive without bulk permissions).

Task description: Grant temporary access to a specific set of users for training purposes across multiple spaces.

• When/Why: During employee onboarding or when training initiatives are launched.
• Frequency: Seasonal or as needed.
• Pain level: 4 (repetitive task that can be time-consuming).

Task description: Revoke permissions for users who have left the organization/team/project from multiple Confluence spaces.

• When/Why: As employees depart/migrate.
• Frequency: Regularly, as employees migrate.
• Pain level: 7 (critical, but highly tedious and prone to oversight without bulk permissions).

Task description: Align permissions across spaces for compliance with regulatory requirements or company policies.

• When/Why: When new regulations are enacted or company policies are updated.
• Frequency: Periodic, based on policy changes.
• Pain level: 6 (critical for compliance, but complex and error-prone without bulk permissions).

[dhur]

@Shawn Doyle - ReleaseTEAM this is an awesome list! Really appreciate you taking the time to write this up in detail!

[Dave Liao]

@Andy Gladstone - figured you'd have thoughts on chores where a Bulk Space Permissions feature would come in handy. Looping you in for Andy Insights.

This topic is near and dear to me, and Shawn hit a few use cases I've grappled with.

I'm happy Cloud lets you rename groups (in most situations), but when there are group splits and merges, Bulk Space Permissions powers would come in handy.

[dhur]

@Dave Liao Appreciate you tagging @Andy Gladstone on this. It's helpful to hear that group splits/merges is a situation you encounter where lack of bulk space permission management is a pain. 

In the case of a split, is there a common pattern to how permissions should be applied? Should the split group have the same permissions applied as the original group? 

In the case of merging, is there a common pattern to how permissions should be applied?

[Benjamin Horst]

@Shawn Doyle - ReleaseTEAM already mentioned most of the points I have.

Since we just moved to the Confluence Cloud, I'd add: 

• Exchange a group with another 
• When/Why 
  
  • We have set up a lot of "project" groups for access to projects and spaces. The groups can get managed by people in the company. 
  • Pain Level: 5
  • We have to exchange a lot of these groups when we migrate to the Cloud, since we had to change the Identity Provider to one that Atlassian Access supports (Frequency: once, when moving to the Cloud)
  • Sometimes those groups need to be exchanged with others, since the organizational or product groups change.  (Frequency: 4-10 times a year, maybe some more next year, since we integrate with other companies)