A Jira group deletion decision should only happen after the group is no longer needed, default access risk has been reviewed, covered sources show no detected blocking references, manual-check areas are understood, and evidence is saved before deletion.
Use this guide to decide the next review route.
Why this matters
Atlassian warns admins to check whether a group is used to configure app permissions before deleting it. That warning matters because deletion can remove a shared access path while leaving little context for the next admin.
The safer workflow is to prove that the group is unused or replaceable, remove permissions where appropriate, record the decision, and only then delete the group.
For this question, the useful answer should help an admin decide what to check now, which rows to hold out, and which proof should survive after the change. That is why this page stays inside a narrow operational boundary instead of becoming a general governance essay.
Review the group cleanup risk before the Jira change
If this group may be deleted, renamed, replaced, or used in shared permissions, review Group Cleanup Radar first. The useful buying question is whether another reviewer needs exact usage and evidence before the admin changes anything.
Working scenario
A platform owner asks whether an old group can be removed before a renewal cleanup. The group has few members, but it may still be used in a shared permission scheme. The admin needs a yes, no, or hold answer that can survive review.
Define Safe Deletion
Safe deletion means more than no obvious complaints. It means the group is not required for app access, project access, shared schemes, role assignments, automations, filters, or externally managed provisioning.
Write down what deletion is meant to accomplish: reduce clutter, remove stale access, retire a migration artifact, or consolidate groups. The reason affects what proof is enough.
Check Default And Product Access Status
Do not delete a group that is a default access group or default group for an app role. Atlassian documents default groups as a product-access mechanism, so they need separate review from Jira project permissions.
If the group grants product access, confirm whether removing the group changes billable access, onboarding behavior, or only local Jira permissions.
Review Jira References
Check permission schemes, project or space roles, global permissions, workflow conditions, security levels, notification schemes, filters, dashboards, and automation rules where the group name may be embedded.
Prioritize shared permission schemes because a single reference can affect many projects. If the group appears there, deletion is not ready until the scheme owner accepts a replacement or removal.
Choose Remove, Replace, Or Hold
If users still need the same access, replace the group reference before deletion. If nobody needs the access, remove the permissions first, then delete only after a short validation window.
If ownership is unclear, hold the group and record the blocker. Holding is better than deleting a dependency nobody has reviewed.
Preserve The Audit Trail
Capture the before state, the owner approval, and the final action. Once the group is deleted, the easiest evidence disappears from the live admin screen.
A useful record includes the group name, member count, references found, references removed, approver, date, and post-delete validation result.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Group is a default access group | Which app role uses it and whether another default group is configured. | Do not delete until default-group ownership is changed and validated. |
| Group appears in permission schemes | Permissions granted and all projects sharing each scheme. | Replace or revoke the references before deletion, with scheme-owner approval. |
| Group appears in roles or workflow-related settings | Role usage, workflow conditions, security levels, notifications, and project ownership. | Treat deletion as a project-access change and validate with affected owners. |
| Group is externally managed | Whether SCIM or an identity provider controls the group. | Route deletion to the identity owner or create a local replacement plan. |
| No active references and no members | Scope of search, date reviewed, and whether the name could be recreated later. | Delete only after evidence is saved and the rollback path is understood. |
Common mistakes
Most cleanup errors happen when an admin treats a partial signal as a complete answer. These are the failure modes to watch for on this topic:
- Deleting because the member list is empty.
- Missing permissions assigned to the group through a shared scheme.
- Deleting a group that still controls product access or onboarding behavior.
- Assuming a deleted group can be recreated with the same meaning and dependencies.
- Leaving no record of which references were checked.
Checklist
- Confirm the group is not a default access group.
- Confirm the group is not controlled by an identity provider.
- Review permission schemes and shared scheme usage.
- Review project or space roles, global permissions, and workflow-related references.
- Get owner approval for each active reference removed or replaced.
- Save before and after evidence.