Jira Access Management Best Practices

Oliver Wright_1oqz5i

Hi everyone,

I'm looking to make some Jira access configuration/ process changes for a growing organisation and would appreciate advice from others who have implemented something similar.

We have multiple business functions using Jira with around 30+ Jira projects/spaces across these functions and their teams. Some users work only within their own team, while others need access across multiple projects. We're also likely to have Jira projects linked to Confluence spaces in the future.

What We're Trying to Achieve

• Simple and scalable access management
• Support for cross-project collaboration
• Strong governance and auditability
• Minimal central administration
• Alignment between Jira and Confluence permissions where possible

 

Current Thinking

Our current thinking is:

• Use Entra ID groups for licence assignment only at current and unsure if this should be used further
• Manage Jira access within Jira rather than through Entra ID group synchronisation
• Use Jira groups, project roles and permission schemes to manage access
• Maintain a small number of standard permission schemes
• Delegate some access management to designated project owners where appropriate

 

Questions

1. How do you manage access in a similar environment with multiple teams and around 30 projects/spaces?
   • Jira groups?
   • Project roles?
   • Permission schemes?
   • A combination of these?
2. Do you manage project access directly in Jira, or through your identity platform?
3. Have you successfully delegated access management to Project/Space Administrators without giving them wider Jira administration permissions?
   • Can they manage access only for their own projects/spaces?
   • What controls or limitations do you apply?
4. How do you prevent permission scheme, role or group sprawl as the number of projects grows?
5. If you use both Jira and Confluence, how do you keep permissions aligned between the two platforms?
6. Looking back, what would you do differently if you were designing your Jira access model from scratch?

I'd be particularly interested in hearing how other organisations balance governance with allowing project owners enough control to manage their own teams.

Thanks in advance for any advice.

Staffan Redelius

Hi @Oliver Wright and welcome to the community

Good that you are adressing these issues early since it is a bit of a nightmare to clean up later.

1. Yes, you will need to use all the mentioned features to manage permissions in a good way, Use Entra-id for product access (licensing of applications) that way users will be suspended when their Entra-id account is inactivated. You need to decide to handle free users in i.e Goals, Projects, Studio, JSM customer etc. and if that should be part of the standard "package" when you get access to i.e Jira/Confluence
   
   Use default groups for the applications permissons granting basic permissions (create, edit, view). Global permissions in Jira can only be granted to groups. One key permission is "Browse projects". if you want to have an open instance for all logged in users you can add the permission to one of the default groups. If you want to close down everything and only give acess space by space you need to remove "Browse projects" and only give access by inviting members to specific spaces.
   
   Use space roles for more granular permissions (Manage sprints, Schedule work, Delete comments, Edit work logs) That way granular permissions can be handled by the Space admin by assigning roles
2. Larger customers generally use OKTA or EntraID as an IDP and SSO. It is good for on and off-boarding people but some times people only temporary work in Jira and Confluence for a specific project so you still might need to clean up users manually.
3. Yes project/space roles is used for delegating permissions Space administrators can one set of permissions (delete work items, Edit all worklogs) and members can have (Edit own worklog, edit own comments) The permissions granted by the role can is still managed by permisson schemas connected to the space and can only be managed by a Jira administrator.
4. Well this is kind of hard but try to minimize the number of permission schemas. Create a template project that you base the creation of new projects on. Delegate what is needed to space roles so it can be managed by the team itself. 
5. You can use groups and roles in both Jira and Confluence. The permissions are quite different since the scope of work is vastly different. The princples are the same though; agree on basic permissions that everyone should have, delegate granular permissions to the space owner. 

My last thoughts are:

• Try to use groups and roles for permssions and avoid personal permissions since this will be quite messy to handle and investigate if problems occur.
• I often start with a excel spreadsheet to map out the permissions against roles to get an overview. 
• Governance is key to not loose control,

I hope this gives you some input to start with!

Best regards,
/Staffan