Default groups are Atlassian-managed groups used to grant app roles automatically, while IdP groups are externally managed groups synchronized from an identity provider; both can grant access, but they have different owners, risks, and cleanup paths.
Why this matters
License cleanup fails when admins see two groups on a user and assume they behave the same way. A default group may be local and tied to product access; an IdP group may be read-only and require identity-owner action.
For the query default groups vs scim 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 user belongs to jira-software-users through an Atlassian default group and Engineering-Jira through SCIM. Removing one membership does not remove Jira access because the other path still grants entry.
Understand what default groups do
Default groups are tied to app roles and automatic placement in Atlassian Administration. They are convenient, but they can also add product access faster than cleanup teams expect.
Understand what IdP groups do
IdP groups are managed outside Atlassian and synchronized into the organization. Local admins can review their impact, but membership changes generally belong to the identity owner.
Review users with mixed access paths
Many users have both default-group and IdP-group access. Cleanup must prove which path grants product access and whether another path will keep access alive after removal.
Assign decisions to the right owner
Default-group design is usually an Atlassian admin decision. IdP-group membership is usually an identity decision. Mixed cases need a split record so each owner sees their part.
Keep evidence for renewal and audit
When license spend is questioned, the answer should show the access path and approved decision, not just a list of group names. That evidence keeps savings claims defensible.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| User is in a default Jira access group | Check app role, product access, and whether the group is still the intended default. | Review local product-access cleanup or default-group redesign. |
| User is in a SCIM-synced IdP group | Confirm group source, read-only status, and identity owner. | Route membership change to IdP owner with access evidence. |
| Both groups grant the same access | Test which path keeps access active and whether either path is redundant. | Split the cleanup into local and identity-owned decisions. |
| Default group includes too broad a population | Review onboarding rules, app access settings, and intended users. | Adjust default-group design only after owner approval and impact review. |
| IdP group has local permission references | Check project roles, permission schemes, and group usage. | Send Jira impact evidence before requesting IdP membership changes. |
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:
- Treating default groups and IdP groups as interchangeable.
- Removing one group and assuming Jira access is gone.
- Changing default groups without checking onboarding impact.
- Asking Jira admins to edit identity-owned memberships.
- Ignoring local permission references to synced groups.
Checklist
- Label every relevant group as default, local custom, or IdP-managed.
- Check which groups grant product access.
- Identify who owns each group and membership change.
- Review fallback access before removing one path.
- Document route-outs separately from local actions.
- Keep evidence tied to the user or group cleanup cycle.