I don't understand why this can't be prioritized in 2025...

Many of your customers (particularly Enterprise customers) have to comply with ISO27001 which require activities like regularly reviewing access control policies and procedures.

This is almost impossible to do in admin.atlassian.com and the tools without manually reviewing groups and permissions individually. Understanding what adding / removing groups will do to permissions and product access is a minefield.

Also, I'm conscious that working on this functionality will not make Atlassian any more money. It's not a new product, it's unlikely to encourage users to add more users, it's just making an existing product align with user expectations and value.

If this ever gets worked on and is paywalled behind an Enterprise only feature, I will be deeply disappointed.

Hi, yes this is a real pain to manage the groups properly especially when you try to perform a clean up.

Yeah, let's have AI that hallucinates me some Automation features that don't even exist rather than the ability to find out in which projects a group is permitted - a basic feature as mentioned by so many before.
This is why people I know have become reluctant to use Atlassian Cloud products.

Please Atlassian gert this done sooner than later - it is a security standard to have this. 

How are we supposed to perform effectxive auditing and cleanup on user permissions? 

Obviously this is a sorry gap in what is easily considered a critical function. I'd like to suggest that this feature, when built must go beyond group permissions.

• Groups are used in workflow validators, conditions.
• Groups are used in issue security schemes.
• Groups are used in automations.

This is a huge feature, but critical to making the management of groups over time possible.

Dear Atlassian Team,

please consider at least to implement the group usage as it was in Jira Server/DC. I am referring to this setting: 

• see picture under purpose heading: https://confluence.atlassian.com/jirakb/how-to-identify-group-usage-in-jira-441221524.html

This still lacks the option to see, where a group has project roles but would definitely be a good first step to make it a bit easier for customers to identify group usage in the Cloud. 

In Jira Cloud the only way for customers to currently identify group usage to some extend is through the REST API, as SQL is not an option in the Cloud. Or Atlassian Support is kind enough to execute the SQL Statements...

But in my opinion utilizing the REST API ( through curl or Python Scripts) shouldn't be the first step for customers that they need to rely on. It would be better if there would be at least some fundamental reporting features through the GUI for group usage. (perhaps in Atlassian Administration > groups > open a group > three dots > show group usage). 

Or implementing something similar for Jira like the admin tool "User access" that can be found in Confluence Cloud, that allows to create a CSV report, to get a high-level overview in which spaces a group is being used. 

Kind regards,

Christian Winter 

5+ years gathering interest for one of the most basics IT Controls Request in the Enterprise World.

wow Atlassian...

+1 to wanting this feature implemented.

Well I guess this one is probably on track for delivery ten years after submission.

Please reconsider it as a crucial topic for admins !!!

From now on, I create a Jira support ticket every time I want a list of project permissions per group.
If this really useful and important must-have feature is not implemented, Atlassian Support will have to do the work.

(╯°□°)╯︵ ┻━┻

750+ votes

and "will not be able to implement this suggestion in the next 12-18 months. We will be maintaining this ticket's status as "Gathering Interest" in order to continue learning from all of you about pain points and challenges relating to this suggestion."

(╯°□°)╯︵ ┻━┻

It really isn't that complicated that you need to learn more. You already have a ton of comments. Instead of sending out surveys asking about what pricing structure we would be able to pay for if you offered your products bundled together, you could simply drop a form to gather the pain points and actually fix the issues your products have? (Yes, this is an issue - we cannot administrate the products effectively.

What will it take to finally have the Atlassian team realize that this is a critical, must-have feature?

Let me be very clear: It is currently impossible to administrate the tools based on any reasonable security standard. How are we supposed to perform auditing and cleanup on effective user permissions? Through self-concocted curl scripts?

We are not talking about bells and whistles here. This is an essential part of basic administration functionality which has been terribly neglected for years.

Get. It. Done.

This ticket has existed for 5 years and now you are telling us that it will not even be considered for the next 12 to 18 months? That's really sad, especially when you see all the "vital" features and trials that have been rolled out recently. Of course I understand that it's more fun to implement new cool features to get new customers, but I hope to get back into Atlassian's focus as an existing customer at some point. Please excuse my sullenness, but this is unfortunately just one of the tickets (with a not insignificant number of votes) I am eagerly waiting for to be able to do my job meaningfully and where there has been a very similar response recently.

This is really key function especially after migrations from server to cloud, after switching from different IAM technologies, acquisitions and so on. I am taking care of an instance where AD was used first, later on switched to Okta. I got mixture of several hundreds of groups of unknown purpose. On top we have acquired another 3 companies with 3 instances and got mixed up another set of groups. I agree that this functionality should cover all potential objects where groups are used (permissions schemes, filters, dashboards, automations, workflows etc.).

It will be very helpful to have these features specially for user access review.
I am surprise that Atlassian has not implemented yet.

A must-have feature! It's a big omission - Jira/Confluence should facilitate security scans and user management better than this. 

Para organizaciones grandes esta función es ABSOLUTAMENTE básica.

My company's Jira product usage goes back to about a decade. We have several pages worth of permission groups and figuring out what has access to what is an incredibly manual task that is very open to user error. 

A feature clearly outlining what projects a group is associated with would be a monumental time saver in cleaning and organizing group structure company-wide. 

This would be a great feature. Especially as we move from Jira Groups to AD sync'e ones for projects.

Currently auditing the groups for my org and its hassle when we only have 100 - 200 users. Couldn't imagine what the effort to do this for a large organization. Hopefully a native capability is added because it would save a lot of time.

This would 100% increase every organization's change control processes

Please prioritize this! It should be a mandatory feature in such systems!

I'm interested, it would be great to be able to see what Spaces/Projects a group has access to.

People here should be aware that groups are used across Atlassian services, so the suggested workaround doesn't show all potential use. There might be a group that's not used in Jira permission schemes but is used for Confluence. I don't know of a definitive and easy way to determine whether a group is used or not.

Am going through a consolidation exercise, having migrated from local groups to Azure groups, it'd be really helpful to be able to remove the old local groups and remove the potential for parallel admin.

This is critical functionality for us. We are moving to Azure AD user provisioning so will need to replace all of our existing groups with our Active Directory groups, except between Jira and Confluence we have no idea what any of these grups have access to!!!

When looking at fields, screens, etc it tells you excactly where these are being used so they are super easy to clean up, yet we cannot see where any groups are being used?

Dear All,

Can you tell me how I can find group usage in automations, workflow rules, schemes with API or other way? 

Thanks! 

Hi,

In order to check which projects a certain Group can access, I use the following workaround, that works fine at least for my needs.

I have created an account for testing purposes. Let's call it TEST_ACCOUNT

When I need to check the permissions related to a certain Group "X", I add the TEST_ACCOUNT to the Group "X" (removing this account from any other groups that have any roles associated across the projects).

I go to Settings>User Management>TEST_ACCOUNT>View Jira project roles, and there I can see the projects the Group "X" has access to, with the roles per each project.

 I hope this can help.

Wow... almost 5 years ago the Issue was created and almost 600 votes for it. And guess what? Atlassian didn't even start to implement somthing...

https://getsupport.atlassian.com/browse/PCS-256844

It will be nice to have this features as it is very difficult to have user access review during audit months.

It is unbelievable that this feature is not yet supported. Yet again another proof that Jira is a class B product. Seriously considering migrating to other solution.

+1 We do use the API to gather a full list of users, groups, roles, products, and permissions for SOX UARs but don't want to go through that when determining which group is the best for a person being added to Jira.  Would like to see a listing in the admin area that is filterable and sortable.  Also, a list of which projects and the project role a group has access to when you are in the Groups area and have selected a specific group.

I'm specifically looking for the groups linked from my identify provider (azure) and how they relate to each project, in a bulk download (ie not going to each project separately for the data)

This is critical to have the ability to see what groups have access to what projects.  Especially if there are multiple admins over the years without any formal naming conventions!  We are doing better now, but still have hundreds of groups that have specific access or access to several projects, and there is no easy way to see what access a user gets by adding them to any group!

Please add this!

Any update on this?

My job is to tidy up the groups, which is very difficult without this feature.

This feature is strongly required. 

It could be solved even with a workaround like a CSV / JSON / XML export or whatever readable format of Group-Project assignments to do the analysis in another tool.

I'll just repeat it. Yes, we really need this feature. There are audits, administrators are changing. I need to be able to indicate what, and at what level, a given user or group has access to.

Please fix this, the number of votes should be more than enough by now..

This is ridiculous ... This is a BASIC IAM feature, how can it be that Atlassian did not fix this when launching their products???
The fact that this is missing is simply unbelievable. 

UPPPP

We have 1000 users and 1200 projects and it's impossible to figure out who has access to what - not at least because we have all our customers in the installation so we probably have at least 300 groups, including our internal ones.

I need a solution that will tell me exactly what elements a certain group or a certain user has access to - accross products.

David Meredith, you are absolutely spot on. It really is one of the absolute worst things in administering these tools. Also, because we don't have the user admin role rolled out yet for us.. we have two org admins tending to all group management requests for 1.000+ users.

I can imagine it's a hard sell in Atlassian to invest in these areas because these aren't exactly flashy features for the front page. But we are talking about keeping especially the big customers happy - which should provide sufficient motivation.

Let's play a game... I want to add/remove users in a group or delete a group. Is it used in?:

• Site Access
  • Product Access
  • Admin Access
• Global Permissions
• App Permissions
• Confluence Spaces
•  Projects
  • Roles
    • Default groups
  • Permission Schemes
  • Issue Security
  • Workflow conditions
  • Automation Rules
  • Security Levels
• Filters
• Dashboards
• Asset
  • Schema Permissions

This is assuming you only have JSW + Confluence. How the hell are we expected to administer these systems effectively if you need to check all these places manually or with an unsupported python script?

EDIT: The script only actually shows you where groups appear in permission schemes which is marginally better than nothing.

Please assign this to someone and implement some actual built-in functionality to help us manage groups effectively.

We desperately need this feature implemented. Managing group permissions is near impossible with an instance with hundreds of projects and hundreds of groups. This is a core need for admins.

I think having the Project Roles listed in the Groups page would be great, especially from an audit standpoint, makes things much easier.  

To that I would like to add, it would be nice if you could add a group to a project and role from the Group page itself much like when you create a Custom Field and can add it to a Screen.  It would be nice to have a project multi select box and a project roles multi select box.  
 

Atlassian has come a long way and so has the products. In many cases Jira/Confluence products have been used since the server, sucked in several other tracking tools, expanded to DC and then may be to cloud and across several admin teams and guidance. This generally gathers a lot of junk which we normally clean off with housekeeping. But groups are one such item which definitely needs cleanup but is nightmarish without its usage information. Would be great to have this implemented in cloud.

Over the course of 7+ years, our Jira cloud environment has gone through a few different admins, all with their own way of doing things. Now we have well over 100 user groups used across several hundred projects, and I'm in desperate need of a way to clean up, consolidated and curate these groups down to a manageable number without revoking access to projects in the meantime. The amount of manual effort required here could be helped if I could at least focus on one group at a time and validate their project access. It's been almost 3 years - hoping for something soon.

It's astonishing that with 369 votes this is still gathering interest from 2019.  This a basic need for administrators.  This is also needed in Data Centre, not just Cloud please.

Apart from this feature being perfectly logical (you can view the user's accesses to projects, but can't view the group's accesses?), it's very much necessary. We have hundreds of projects and hundreds of groups. Some groups have the access to multiple projects. Complete lack of ability to manage that really holds us back. 

I've been using the export facility on the users / groups to maintain order for now. a bit manual till you get a hang of the spreadsheet / view you want to use. access to the actual group touches / access would be invaluable - as lots of people want access but then rarely access it ... 

Hello Everyone,

I would like to contribute by adding one workaround for this query for all users can retrieve the report, since project settings are constantly changing, I think it is good to have at least one automatic option.

Note that groups are not the only way to gain permissions; project roles, or other entries give permissions. So, if you want to get a precise user permission report, please check my contribution in this comment: https://jira.atlassian.com/browse/JRACLOUD-68146

# file audit-group.sh
# Requirments: install jq and curl
# bash script to run in MacOS, linux or similar terminal
# How to run: ./audit-group.sh


projectkeys=(SCRUM BIT3 BUS3)  # insert here the list of project keys of company-manged projects
APItoken="PutAPITOken" #generate here https://id.atlassian.com/manage-profile/security/api-tokens
AdminEmail="email@domain.com"
tenant="your-cloud-url.atlassian.net"


echo "" > reportGroups.csv
echo -e "permission;group;project" >> reportGroups.csv
for pkey in "${projectkeys[@]}"
do
echo "working on project: $pkey"
schemeid=$(curl -s --request GET --url "https://$tenant/rest/api/3/project/$pkey/permissionscheme" --header 'Accept: application/json' --user $AdminEmail:$APItoken | jq '(.id)')
curl -s --request GET --url "https://$tenant/rest/api/3/permissionscheme/$schemeid" --header 'Accept: application/json' --user $AdminEmail:$APItoken | jq --arg pkey "$pkey" '.permissions[] | select (.holder.type == "group") | ."pkey"=$pkey | "\(.permission); \(.holder.parameter); \(.pkey)"' | tr -d '"' >> reportGroups.csv
done

The reportGroups.csv file should look like this:

thank you, and it is important to mention that script assistance is not part of the cloud support offerings.  

As a Jira Admin

I would like to view all projects associated with a group in the group administration UI

So I can audit the projects a group has access to

Given I am a Jira administrator

When I visit group administration UI

Then I will see "Project Access" listing projects this group has access to under existing "Group Access"

And I will have an option to edit which projects this group can access 

The "list" should include everywhere a group could be in use, not just project permissions.

• automation rules
• filter access
• filter subscriptions
• dashboard access
• anything else?

Same thing for roles, but I guess that'd be a different ticket...

I echo what everyone else has said.  I just spent a week working with support to run the reports for multiple groups.  This shouldn't require a support ticket.

I'd love to see a feature implementing a better way to manage permissions. Especially at scale, going to each project is untenable. I'll need to try pulling it via the API as others have mentioned.