Before deleting a Jira group, what do you check in Jira Cloud?

[Jonas Nilsson _ Unitlane]

I keep coming back to the same Jira Cloud cleanup problem: group cleanup.

Deleting the group is the easy part. Figuring out what it still affects before making the change is the part that gets messy.

Atlassian’s own documentation says the UI does not directly show whether a specific group is used in a permission scheme, and their workaround points admins to the REST API plus Python.

In practice, the first places I keep checking are:

• permission schemes
• project roles

Disclosure: I built Group Impact Audit for Jira for this workflow. It is read-only and focused on showing group references in permission schemes and project roles before cleanup.

Curious how other admins are handling this today.

What do you usually check before removing a group, and are there places people often forget to review?

[Luiz Ricardo Pereira da Silva]

Managing groups in Jira Cloud is a notorious "blind spot" for admins. The fear of hitting "Delete" and unintentionally breaking a critical workflow is real. Since Atlassian’s UI doesn't provide a native "where used" report for groups, you have to be methodical.

Here is a strategic checklist:

1. The "Hidden" Configuration Layers
   
   Beyond Permission Schemes and Project Roles, these are the spots where group dependencies often hide:
   
   Issue Security Schemes: Often overlooked because they aren't used in every project. If a group is the sole grant holder for a security level, deleting it can make those issues inaccessible or default them to unintended visibility.
   
   Shared Filters & Dashboards: This is the #1 cause of "broken" UI reports. If a filter is shared specifically with a group, the filter doesn't disappear, but users lose their access to the data, causing gadgets to show errors.
   
   Notification Schemes: Groups are frequently used to loop in "Lead Developers" or "Management." Removing the group silences these alerts without triggering a system error, leading to missed deadlines.
   
   Board Filter Shares: If a Kanban or Scrum board’s underlying JQL query relies on a filter shared with that group, the board may stop rendering correctly for team members.
   
   
2. Automation & Workflow Logic
   This is where the "silent killers" live. Automation and Workflows often don't "break" hard; they just fail to execute correctly.
   
   Jira Automation (A4J): Rules often contain conditions like User is in group. If the group is deleted, the automation might always evaluate to "False," skipping critical steps in your business process.
   
   Workflow Conditions & Validators: Many workflows restrict transitions (e.g., "Only Managers can Approve") based on group membership. Deleting the group can effectively lock an issue in its current status forever.
   
   Group Picker Custom Fields: If you have custom fields that default to or filter by a specific group, removing that group can lead to data loss in those fields or validation errors during issue creation.
   
   
3. Best Practices for a "Soft Landing"
   Since we lack a native "Impact Analysis" tool in the standard UI, I recommend this 3-step safe-deletion protocol:
   
   The "Z-Prefix" Rename: Rename the group to something like z_DEPRECATED_GroupName. This makes it obvious to other admins and shows up at the bottom of lists.
   
   The "Empty Group" Phase: Remove all users from the group but keep the group itself for 7–14 days. If a permission or automation breaks, you’ll hear about it from users, and you can simply add them back or fix the reference without losing the configuration.
   
   Documentation Check: If you are using Atlassian Access (for SSO/SCIM), ensure the group isn't being pushed from your Identity Provider (like Okta or Azure AD), as the sync might try to recreate it.
   
   
4. Final Thoughts
   Your approach with the Group Impact Audit is excellent because it addresses the core issue: visibility.

One last tip: always check Application Access. Sometimes a group is the only thing granting "Jira Software" or "Jira Service Management" access to a subset of users. Deleting it could accidentally revoke their licenses.

[Rune Rasmussen]

On top of everything @Luiz Ricardo Pereira da Silva mentioned you can use this page page to check Jira Space access:
https://YOUR-SITE.atlassian.net/secure/admin/roles/ViewUserProjectRoles.jspa?accountId=123abx

Use any user from the group you want to check.
At first you get a long list with just check marks or crosses

But if you select "Edit project roles" in the top right, the ones that are granted through group memberships will be indicated like this:

For Confluence Space access you can use the User access report export. It also works for groups.
https://YOUR-SITE.atlassian.net/wiki/admin/user-access