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_ · Accepted solution]

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

[Kieren _SmolSoftware_]

I actually just posted a relevant article to this discussion: SCIM Sync Limitations And How To Overcome Them

[Tomislav Tobijas]

Hi @Monika Rani ,

We have never created local custom groups instead of using the default ones. However, with the new ability to sync user groups with Atlassian Teams, this then makes sense (it has a potential use case).

Also, what we usually do is integrate IdP (such as Entra ID or Okta) and then give product roles to those groups, and all user access/licensing is performed through those. One thing is that you cannot set IdP synced groups as default groups, so we still have those system ones, but we never use them.

If I circle back to how you've designed the system, we did that before having IdP syncs, but in a slightly different way - default groups were used only for licensing, and all those other (custom) groups were used within project/space permissions to give access to specific content.

Cheers,
Tobi