nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best Practices for Managing Jira Cloud Permissions Across Multiple Projects

APKGuideHub

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!

Comments

Sonal Malik

Hi @APKGuideHub

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

Becker_ Rene

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.

---

Rosana Casilli

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.

David Cowley

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.

s_gridnevskii

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.

s_gridnevskii

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.

Rune Rasmussen

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.

Becker_ Rene

> BTW this means that Jira works much faster since user gets much less issues/work items in search results

That's good food for thought. Thank you for adding that hint.

---

s_gridnevskii

@Becker_ Rene this is especially true if you work in an Agile team and you use sprints and boards. One of my teammates has filter with 20000 work items and his board is very very slow. And closing sprint can take 2-3 minutes.

Kade Schemahorn

Great thread! The consensus here (standardized roles + a shared/default scheme + IdP-provisioned groups) matches what scales well. I'll just add the part that tends to stay manual, which is periodic reviews/auditing.

A few things that help:

Separate "who's in which group" from "who can actually do what." The group list is easy. It is effective access across schemes + roles + nested groups where auditing can be slow. Being able to answer "what can this person do, and how did they get it" in one place saves a lot of cross-referencing.
Treat purging of inactive-users as a recurring review rather than a one-off. And mind the gotcha that David flagged, that customer interactions in JSM doesn't update their "last accessed" date. I'd also add that access can be granted via a shared group, so deactivation doesn't always remove what you'd expect.
If you're under SOX/SOC 2/ISO, auditors want evidence of a periodic access review (keep/revoke decisions + sign-off), which is the piece that's hardest to produce from native tooling.

Full disclosure, I just released an app in this space (Access Governance for Jira) precisely because that review + effective-access layer has been manual and painful for folks. It maps effective access, flags inactive seat-holders, and runs attested access reviews that you can export as evidence.

That said, the biggest win here is often just treating access review as a scheduled process with recorded decisions rather than an ad-hoc skim of audit logs.

Fabian Hönes

On question 4: what has worked for the teams I have talked to is to review by group rather than by project — a group is the unit your IdP syncs and the unit auditors ask about, and one group usually touches many projects through permission schemes and roles. The checks that tend to get missed are not the schemes but filters and dashboards shared with a group, filter subscriptions, and the default group for product access; none of those show up in a project-by-project review. Whatever you use, keep the result with a date — the next review starts from the diff.

Disclosure: I'm the developer of a read-only Marketplace app that runs exactly that per-group check and exports it as CSV; mentioning it because it fits the question, not as a replacement for the audit log you already use. https://marketplace.atlassian.com/apps/1133367000

Welcome!

It looks like you're new here. Sign in or register to get started.