Atlassian default groups are groups associated with app roles so users can be granted access consistently. They often become the main path for Jira or Confluence product access because users are added during invitation, role assignment, or onboarding. Default groups are useful, but risky when they grant too many apps, lack ownership, or remain unchanged after teams evolve. Review default groups before major license cleanup or access-policy changes.
Why this matters
Default groups quietly shape who gets access to Atlassian apps. They are convenient because admins do not have to choose a group from scratch for every new user, but they can also preserve old assumptions for years. If a default group grants Jira to every employee, Jira access becomes the baseline even when only some teams need it. If a default group grants multiple apps, user access admins may be constrained and removals can have wider effects than expected. Default groups also matter during cleanup because they can be required for an app role and may block removal unless a replacement default exists. Admins should treat them as policy settings with owners, evidence, and periodic review, not as invisible plumbing.
For the query default groups product access 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 growing company started with a simple all-staff group that granted Jira Software and Confluence. Later, Jira usage became limited to product, engineering, support, and operations, but the all-staff group remained the default for Jira. New hires in finance and HR still received Jira even though they rarely used it. During license review, the admin identifies the all-staff default group as the largest Jira access path. The fix is not to delete the group immediately. The team creates a narrower Jira default group, updates onboarding policy, moves legitimate users, and records exceptions before removing Jira access from all-staff.
Understand what default groups do
Default groups provide a standard group path for app roles. When a user is granted access to an app role, Atlassian can add the user to the relevant default group. This makes provisioning easier and helps admins apply consistent access. The risk is that the default group becomes the organization-wide answer to every access question. Over time, a default group might include users who no longer need the app or might grant more apps than the current onboarding policy intends. Default groups should therefore be documented with the app role, owner, purpose, and expected population. Without that documentation, every cleanup effort must rediscover why the group exists before deciding whether it is still valid. The record should make future onboarding and cleanup decisions faster, not just describe the current setting.
Check whether default groups grant multiple apps
A default group that grants more than one app can create operational friction. It may be convenient for broad onboarding, but it makes app-specific cleanup harder. Removing a user from the group to take away Jira may also remove Confluence. Removing app access from the group may affect many users and another app's access model. Atlassian also distinguishes what user access admins can do when default groups include apps outside their administration scope. For a clean review, list every app each default group grants. Then decide whether multi-app grouping is intentional, documented, and still appropriate. If not, plan a split into narrower groups rather than repeatedly handling exceptions at the user level. This helps admins preserve legitimate baseline access while reducing accidental paid access.
Treat default-group changes as policy changes
Changing default groups affects future users, not only current users. If you change the default group for a Jira role, new Jira users may be provisioned differently tomorrow. If you remove app access from a default group, the app may require another default group before the change is allowed. This is why default-group cleanup should go through a policy owner or organization-admin review. The decision should state the old default, the new default or replacement pattern, affected apps, and how existing users will be handled. A default-group change is a good opportunity to align onboarding with actual job roles. It is a bad place for an unreviewed quick fix during renewal pressure. Include a dated approval so future admins can distinguish policy from drift.
Review users who inherited access from defaults
After default groups are understood, review users who inherited product access from them. Segment users by active need, team owner, account type, and alternate access paths. Some users should remain in the default group because it matches their role. Some should move to a narrower app-specific group. Some should lose app access entirely. Others may be managed through the identity provider and need a routed change. The goal is to avoid turning default-group cleanup into a mass removal with no context. For license savings, calculate only users who lose the paid app completely. Users who move from one Jira-granting group to another may improve governance without reducing the user tier. This segmentation makes the expected license effect realistic before any user is removed.
Keep an audit trail for default-group decisions
Default-group decisions are easy to forget because they are made infrequently. Keep a short evidence record with the reason for the current default, owner, date reviewed, apps granted, and known exceptions. If the organization changes structure later, the next admin can see why Jira access is or is not part of baseline onboarding. This record also helps explain renewal cleanup. Finance may ask why a broad group still grants Jira; security may ask why a default group changed; team owners may ask why new hires no longer receive automatic access. A dated decision record turns those questions into a normal review conversation instead of a console archaeology exercise. Store the decision where the next access review will actually find it.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Default group grants Jira to all employees | Check whether Jira is still a baseline app for all employees. | Create a narrower default or approved exception model if baseline access is no longer valid. |
| Default group grants multiple apps | List all apps and admin scopes affected by the group. | Split into app-specific groups if cleanup or delegated admin work is blocked. |
| Group is the only default for an app role | Confirm app role requirements before removing access from the group. | Assign a replacement default group before retiring the old one. |
| Default group has no owner | Check onboarding policy and recent provisioning use. | Assign ownership before making product-access changes. |
| Users inherited access through default onboarding | Compare current job role and app need against the default policy. | Move, remove, or hold users based on owner-reviewed need. |
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 as harmless background configuration.
- Removing app access from a default group without a replacement.
- Letting one default group grant multiple apps unintentionally.
- Expecting user-level cleanup to fix a broad default onboarding policy.
- Failing to document why a default group still grants Jira.
Checklist
- List default groups for each app role under review.
- Record which apps each default group grants.
- Confirm whether each default group has an owner and documented purpose.
- Check whether the group is the only default for a role.
- Review whether current onboarding policy still matches the default group.
- Segment inherited users by active need, exception, and alternate path.
- Record the default-group decision and next review date.