Best Practices for Managing Jira Cloud Permissions Across Multiple Projects

Hi everyone,

I'm looking for recommendations on efficiently managing user permissions in Jira Cloud, especially for organizations with multiple teams and projects.

I'm interested in learning:

How do you organize project roles and permission schemes?
Do you use shared permission schemes across projects or separate ones?
What are your best practices for onboarding new users while maintaining security?
How do you regularly review and audit permissions?

I'd appreciate hearing about your real-world experience, any challenges you've faced, and the strategies that have worked well for your organization.

Thanks in advance for your insights!

5 comments

Comment

Hi @Muhammad Shakeel

In my view as a cybersecurity project

How do you organize project roles and permission schemes?

Roles are based upon requirements. I have created my own schemes. The most efficient way to manage permissions is to use Project Roles as the bridge between users and permission schemes.

Do you use shared permission schemes across projects or separate ones?

Both. Shared Schemes (Recommended)

What are your best practices for onboarding new users while maintaining security?

I don't allow anyone to even request access. I myself add customers to a customer group and provide agent access only.

How do you regularly review and audit permissions?

Export for Analysis, checking Audit logs.

Regards,

Sonal

We have ~800 projects/spaces.

We use standardized roles in projects.

Except for some exceptions, we only use 1 permission scheme.

For each project and each role, there is a group in the Site Directory (admin.atlassian.com). In our case they are provisioned via Entra.

For two roles, the mapped groups are always the same (removed if "secret" project). All other roles are mapped to groups manually.

This way we keep control and do not have to act if only default are needed (company wide, not-secret projects).

Projects where defaults will not suffice: ~50.

Audit is done via our JSM, where we have a dedicated work item type + WFL for permissions.

---

Hi Muhammad!!!

Great questions!!

Here my answers from my perspective (Site Administrator and also a project owner)

How do you organize project roles and permission schemes?

We have some default roles in our instance and some additional ones. We have those roles documented so everybody knows what they are used for. On the other hand, we have a default permission scheme that is shared with certain projects. When requirements demand restricting actions within a project to specific people or groups, those projects get a specific permission scheme. As Sonal mentioned in another comment, schemes, roles, and users/groups are the key.

Do you use shared permission schemes across projects or separate ones?

I use both. As I mentioned before, when needed, we have separate permission schemes, but it is not the usual approach

What are your best practices for onboarding new users while maintaining security?

I have my own portal in Jira Service Management where people from the company request product access. It follows an approval workflow where the Security team must approve the request before creating the user and granting access to an Atlassian product. These requests are always submitted by the team managers of the new users.

How do you regularly review and audit permissions?

I check for audit logs.

All our permission schemes use roles as the basis for assigning permissions.

Most projects use our standard default permission scheme, although we do have a couple of "options", as necessary we apply custom schemes, but they have to convince us they really are a special snowflake in order to get one.

So yes, schemes are mostly shared, but not all.

We have user access requests handled through JSM, requests must be submitted for access to a particular Jira/Confluence Space or JSM portal, and the request must either come from someone who is a Space Lead or in an Admin role on that project.

We grant appropriate product license, they assign the user to their role in the space.

Space Leads/Admins are responsible for auditing their users/roles. We prompt them at least annually to do so, but we don't have the relevant knowledge to do the audits ourselves (we can't know if someone who is still an employee is no longer involved in the work of a given space).

We have started purging account permissions for users who haven't accessed any of the systems in 6 months. We're still working on perfecting our suite of API script for this. It's also worth mentioning that if you're using the last accessed (or is it last seen) column, that value does not include interactions with JSM as a customer, so someone could not be using Jira or Confluence, but actively been engaging submitting tickets through JSM and you wouldn't know it from the user export data.

Like • like this

In fact we also manage access to Jira projects in JSM. But these requests are approved by project owners who can be people not directly related to Jira, e.g. department head. All projects are stored in assets database and we have separate requests to create a new project in Jira that automatically adds new project to database.

We have same permission scheme for all projects which was agreed with management and security team. The scheme is roll-based. We have dedicated roles for project members, managers, project administrators and security.

When a new project is created we do not add individual members there. Each role is assigned to a group.

We have 2 kinds of groups: Teams and Common groups. Teams can have access to several projects, usually they follow department structure. Common groups have access to one project only.

Groups are named in standard way.

JIRA_TEAM_department

JIRA_MEMBERS_project
JIRA_MANAGERS_project
JIRA_ADMINS_project

When we onboard employee he is added to AD group of his department and to common group of projects he is involved in. This is done by automatic scenario based on his company role description. In a couple of minutes he gets access to all projects he needs.

If an employee from another department needs access to specific issue/work item in a project we have a special custom field of type "multiple users". Permission scheme gives access to this specific issue to the user who is mentioned in the field.

We have 2 separate permission schemes for archived projects (no access to anyone but Secutity team) and projects in view only mode.

This approach helps us to onboard employees flawlessly and also limit access to projects to those who need access. BTW this means that Jira works much faster since user gets much less issues/work items in search results.

We do not perform audit since all our groups are in AD and if employee leaves company he gets removed from Jira automatically. We have a python script that checks if any project has individual users and reports results to security team. Project admins know that they are not allowed to add users to projects and if they forget logs show who is guilty.

How do you organize project roles and permission schemes?
- Since Roles are global we try to have a few as possible.
  User can do work. (be assignee, change status, and such).
  Admin can administrate.
  These to are accumulative. The Admin is not User with admin permissions.
  In general Any logged in user can browse space, comment, and edit work items. This makes cross space collaboration easier.
Do you use shared permission schemes across projects or separate ones?
- For Permission Schemes we have one standard "transparency first" Scheme.
  For Spaces that has an explicit and absolute need to be secreted away we set up individual Schemes for their needs. The core concept of User work, Admins administrate still applies.
What are your best practices for onboarding new users while maintaining security?
- Product access/license is requested and approved through a ticket.
  Specific access into individual Spaces are done by their respective Space Owners.
How do you regularly review and audit permissions?
- That is delegated to the Space Owners.
  As the site grows in number of Spaces and number of users it becomes increasingly impossible for product admins to police who should have access to what.