Externally managed groups in Atlassian are groups whose membership is controlled outside Atlassian, usually through an identity provider and SCIM, so local admins should review what the group grants but route membership changes to the identity owner.
Why this matters
Externally managed groups create a boundary between discovery and action. Jira admins may see that a group grants product access or project permissions, but the durable membership change may belong to the IdP owner.
For the query externally managed groups Atlassian, 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
A group named Engineering-Jira-Users appears in Atlassian and grants Jira access. It is read-only because it syncs from the identity provider. The local admin can review its impact, but the identity team must approve and make membership changes.
Recognize the ownership boundary
If the group is synced or read-only, the local admin should not treat it like an ordinary Atlassian group. The review can explain impact, but the identity owner controls membership.
Review what the group grants
Externally managed does not mean irrelevant. The group may grant app access, admin privileges, or Jira project permissions. Before routing a case out, capture what the group actually affects.
Keep local default groups separate
A default Atlassian group can coexist with synced IdP groups. Cleanup gets confusing when admins treat both as the same source just because both appear on a user's profile.
Document the handoff
A useful route-out includes group name, source, access impact, user or population affected, requested decision, and the identity owner. That evidence makes the handoff actionable.
Review usage before group cleanup
If the group itself is being retired or replaced, inspect where it is referenced before deletion or rename. Externally managed membership is only one part of the risk.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Group is read-only or synced | Confirm provisioning source and identity owner. | Route membership changes to the IdP owner with access-impact evidence. |
| Group grants Jira product access | Check app access settings and whether the group contributes to billable access. | Review license impact and route membership change to the owner if synced. |
| Group appears in project permissions | Trace permission schemes, project roles, and global permissions where relevant. | Use impact evidence before asking the identity owner to change membership or retire the group. |
| Group conflicts with a default or built-in group name | Check naming, sync behavior, and Atlassian guidance on group conflicts. | Resolve naming at the source of ownership rather than patching locally. |
| Group is being replaced | Confirm old and new group usage before moving membership. | Build a migration evidence pack and approve cleanup only after references are 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:
- Trying to edit synced group membership locally.
- Assuming externally managed groups cannot create license waste.
- Ignoring where a synced group is used in Jira permissions.
- Mixing default-group cleanup with IdP-group cleanup.
- Routing a case to identity without evidence of what the group grants.
Checklist
- Confirm whether the group is local or externally managed.
- Identify the identity owner before requesting membership changes.
- Review product access, admin access, and project references separately.
- Check whether a local default group also grants access.
- Preserve evidence when routing the change out of local admin work.
- Review group usage before delete, rename, or replacement.