To review group product access in Atlassian, list the groups that have app roles, identify which apps each group grants, and compare that to the group's purpose, owner, member count, and management source. Then separate groups to keep, groups to clean up, groups that need owner approval, and groups managed by an identity provider. The goal is to understand app-access policy before changing user memberships or removing group app roles.
Why this matters
Group product access is where Atlassian license drift usually becomes structural. Individual users come and go, but broad groups keep granting app roles month after month. If a group outlives its purpose, every new or retained member can inherit unnecessary Jira or Confluence access. If a group grants multiple apps, it can inflate several user tiers at once. A good review gives admins a policy-level view: which groups grant each app, whether those groups still match business ownership, and which changes are safe. It also prevents cleanup teams from spending all their time on individual users while the source group continues to create new access. Group review is the bridge between license cleanup and access governance. It also gives finance a cleaner explanation of why some groups were left alone even though they carry paid access.
For the query review product access for groups, 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.
Working scenario
Before renewal, the platform team reviews every group that grants Jira Software access. They find default groups for employees, project groups from completed migrations, department groups synced from the identity provider, and a few ad hoc groups created by admins during incidents. Some groups should stay. Some should lose Jira access. Some need member cleanup rather than group-level changes. The team builds a decision table with group owner, app roles, member count, default status, management source, and recommended action. Finance gets an expected savings view, while admins get a safer work queue.
Build a group-to-app inventory
The review starts with an inventory of groups and their app roles. For each group, record the Atlassian apps it grants, such as Jira Software, Jira Service Management, or Confluence. Include whether the group is a default group for an app role and whether it grants more than one app. This inventory should be app-centric, not only user-centric, because group policy is what creates repeatable access. A group with five current members might still be risky if it is part of onboarding and will receive hundreds of users later. Conversely, a large group may be appropriate if it represents all employees who should have Confluence. The inventory turns scattered console facts into a reviewable access map. Reviewers should be able to rebuild the app-access picture from this inventory without opening every group again.
Attach ownership and purpose
A group without a known owner is hard to approve for cleanup or retention. After mapping app roles, attach a business or technical owner to each group. The owner should be able to answer what the group is for, who should be in it, and whether the app roles are still needed. Purpose matters because the right action is not always removing product access. A real team group may only need member cleanup. A migration group may be ready for retirement. A default group may need policy review. A synced department group may need identity-owner involvement. Ownership converts the review from a raw access list into a set of accountable decisions. If no owner accepts the group, route it to a governance queue instead of guessing.
Classify the management source
Groups can be managed locally in Atlassian Administration or synced from an identity provider. The management source determines who can make membership changes and how durable a cleanup action will be. A local group may be cleaned up by an organization admin or user access admin with the right scope. A synced group usually requires a change in the identity provider. Some groups can have local app access assigned while membership remains externally controlled, creating split ownership. Record that boundary clearly. Otherwise, a cleanup plan may assign impossible work to the Atlassian admin or close rows that will be undone by sync. The review output should say local action, identity route-out, or mixed ownership. This is especially important when membership and app-role assignment have different owners.
Prioritize by impact and confidence
Not every group deserves the same level of review. Prioritize groups that grant paid apps, have high member counts, have unclear ownership, or are known migration and project artifacts. Also prioritize groups that grant multiple apps, because the cleanup impact and risk are larger. Confidence matters as much as impact. A group with a clear owner and a documented purpose may be low risk even when it is large. A small group with no owner and Jira access may be suspicious because nobody can justify it. Use lanes such as keep, remove app access, clean membership, route to identity, and hold for owner review. This prevents the review from becoming an endless spreadsheet sorted only by size. Document confidence so a high-impact but uncertain group does not get changed too quickly.
Use the review to guide removals
A group product-access review should produce actions, not only observations. For each group, decide whether to keep app access, remove app access, change membership, replace a default group, or route to another owner. Then verify affected users before making changes. If the group loses Jira access, identify users who will lose Jira entirely and users who will keep it through another path. If membership changes are recommended, decide whether the cleanup is local or identity-owned. Keep evidence for the current app roles, decision owner, and expected impact. The practical value of group review is that later user removals become easier because the underlying group policy is clearer. If an action is deferred, write the reason and the trigger for reassessment.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Group grants Jira and has no owner | Check naming, creation context, current members, and recent activity. | Hold removal until an owner or governance approver signs off. |
| Group grants multiple paid apps | Confirm whether the group purpose really spans all apps. | Review as a multi-app policy group before changing roles. |
| Group is a completed migration artifact | Check whether active users have alternate valid access paths. | Retire or remove app access after owner approval and impact review. |
| Group is synced from identity provider | Confirm who owns membership and whether app role assignment is local. | Split the action into local app-role review and identity membership review. |
| Group is a default group | Check role requirements, onboarding use, and replacement default groups. | Treat changes as access-policy work, not routine cleanup. |
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:
- Reviewing users while ignoring the groups that keep granting access.
- Changing app access for a group without owner approval.
- Treating synced and local groups as the same cleanup workflow.
- Missing default-group behavior during group review.
- Sorting only by member count instead of impact, confidence, and ownership.
Checklist
- Export or list groups that grant each Atlassian app role.
- Record app roles, default-group status, and multi-app access.
- Attach group owner, purpose, and management source.
- Flag high-member, no-owner, migration, and multi-app groups.
- Classify each group as keep, remove app access, clean membership, route out, or hold.
- Measure affected users before group-level changes.
- Keep evidence for the decision and post-change state.