How to Manage Atlassian Groups Better

Monika Rani

Hi there,

We’re not using Atlassian's default groups for product access or permissions at all. Instead, we're:

• Creating our own custom groups.

• Setting these custom groups as the default groups under Product Access settings.

• Managing all permissions and access through these custom groups.

I want to understand if this is a best practice or if anyone has used it before?

Kieren _SmolSoftware__ar1cj1

I've talked to a lot of Atlassian customers about their Group and Administration setups, here's my thoughts on it:

For Product Access

1. It's usually easier and less hassle to only have one or two groups that grant access to a single product. This means fewer issues when it comes to granting access, but more importantly auditing or removing access. Having a quick way to remove access from a user is always important if you're under time pressure, or having only a few groups to sort though for auditing requests is simpler. This is more true for manual user management, less so if you're managing via an IdP. But keeping things simple is always better...

2. Since you always need a default group for each product, keeping product access to a few groups can be challenging, especially if you don't have control over your IdP groups. You can mitigate this by using the Add user to Groups API and scripts to move users into and out of the default groups, or an app like Admin Automations to automate it (note: I build this app. Sorry, had to do a relevant plug 😄).

3. Avoid adding multiple product accesses to one group. It can become very limiting, very quickly, when you can't grant one product or the other at a time. It's also an issue when trying to audit product access...

For Project and Space Access

4. Use Role-Based Access Control (RBAC) when creating groups for Project and Space access, or other permissions within Jira and Confluence. e.g. developers group gets access to certain projects, HR group gets access to certain spaces.

5. The default Atlassian groups grant both Product Access and standard Project/Space access. This is great for new customers who just want basic permissions setup initially, but doesn't lend itself to complex larger customers who aren't as open with their projects across the whole company like Atlassian is. I wouldn't recommend removing the groups or all their permissions, trying to make the groups benign. I'd just caution using them project and space access, unless you're certain that those projects or spaces will always be available to all your staff, like your main confluence space for example.

6. Please please please, document your groups and what they grant access to somewhere! Atlassian don't provide the tools necessary to easily audit a complex group, role, permissions, project and space setup. There are some marketplace apps that can help with that, or you can just document it as you go.

7. Keep a consistent naming convention, something that aligns with your department or role structure usually works best. Like: IT-Admins-Atlassian, IT-Admins-Figma, HR-Managers. It'll make it easier to audit and understand. Try to avoid project names in your groups or permissions as they're transient and don't give any context, though this is often unavoidable given the way software teams work!

 

I'm sure there's more, but I'm tired and should go to bed 🛌.

-Kieren