Atlassian app access is the right to use a specific Atlassian app, such as Jira Software, Jira Service Management, or Confluence, on a site. Admins grant it by assigning app roles to users or groups in Atlassian Administration. Groups can also apply in-app permissions, but those permissions are not the same as app access. For cleanup, remove or review every group and role that gives the target app.
Why this matters
App access is where access management, billing, and team operations meet. A user might be in the organization directory but not have access to a paid app. Another user might have app access because they were placed in a broad group during onboarding, even if they no longer work in that product area. Admins need precise language because Atlassian pages, team requests, and finance reports may use product, app, role, and license as if they are interchangeable. They are not. App access answers whether a user can use a named Atlassian app. In-app permissions answer what that user can see or do inside the app. Cleanup decisions should prove the app-access source first, then confirm whether the user should keep, lose, or transfer that access.
For the query atlassian app access, 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
An organization added Confluence and Jira Service Management during the year. The onboarding group for all employees was granted Confluence access, while support-team groups were granted Jira Service Management access. Months later, finance asks for an app-by-app access review before renewal. The admin cannot simply export all users and remove inactive accounts because some users need Confluence only, some need Jira Software only, and some have multiple apps through a combination of default and team groups. The work is to separate each app role, identify which groups grant that role, and create an action list that does not accidentally remove the wrong app.
Use app names and roles precisely
Atlassian app access should be reviewed at the app and site level. A user may have access to Jira Software on one site, Confluence on another, and no access to Jira Service Management. The app role is the operational fact to inspect. When admins use a broad phrase like Atlassian access, stakeholders often assume it means every product, while the console may show specific app roles. Start each review with the exact app, site, and role. Then list the groups that assign that role. This keeps a Jira cleanup task from accidentally becoming a Confluence removal task, and it keeps finance conversations tied to the app that actually drives the user tier. Precision also helps when user access admins have rights for one app but not another.
Understand the two access layers
Atlassian's app-access model has two layers that admins should not merge. The first layer assigns an app role and lets the user enter the app. The second layer lives inside the app and decides what the user can see or do. In Jira, that second layer includes permissions, project roles, permission schemes, global permissions, and sometimes issue security. In Confluence, it includes space permissions and restrictions. Groups can participate in both layers, which is why reviews become confusing. A group might grant app access, in-app permissions, or both. The practical review question is not only whether a user belongs to a group. It is what that group does at each layer. A clean article, ticket, or evidence record should name the layer being changed.
Review groups before reviewing users one by one
When a large cleanup batch is driven by app access, reviewing users one by one is slow and error-prone. A better starting point is the group-to-app mapping. Identify every group that grants the app role, then evaluate whether each group is still appropriate. Some groups will be current team groups. Some will be legacy migration groups. Some will be default groups that should stay but need clearer ownership. Once the group paths are known, user review becomes more actionable because each user can be associated with a path and a decision lane. The admin can remove a direct app role, remove a local group membership, request an IdP change, or hold an exception. Without group review, the same user may reappear in the paid app through another group after cleanup.
Account for default groups and access requests
Default groups make app access faster to administer, but they also turn into hidden policy. When a role is assigned, a user may be added to the default group for that app role. If the group has been modified to include multiple apps, granting or removing one app can affect a wider access pattern. Access requests add another workflow consideration because a user may request access that is then approved into a default or selected group. For cleanup, admins should check which groups are defaults, which admins can approve requests, and whether default groups grant more than one app. The answer determines whether the cleanup is a normal user-removal task or a policy review that needs organization-admin attention. It also tells the admin whether a user access admin has enough scope to complete the action or must escalate.
Tie cleanup to evidence and ownership
Good app-access cleanup leaves a record that another admin can understand after the console state changes. The record should show the app, role, group path, user count, owner, and decision. For small teams, a structured checklist may be enough. For larger environments, the evidence needs to survive handoffs between finance, IT operations, security, and business owners. This is especially important where app access is managed by a mix of local Atlassian groups and SCIM-synced groups. A local admin might be able to revoke a direct app role but not change the identity-provider group that will later regrant access. The evidence should make that distinction visible so unresolved rows do not look like completed cleanup. For renewal work, that difference should be visible before savings are reported.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| User has app access but no active team request | Check direct roles, group roles, default groups, and recent ownership notes. | Move to candidate review, not immediate removal, until the owner decision is recorded. |
| One group grants several apps | Confirm whether removing app access from the group affects Jira, Confluence, or JSM together. | Treat as an app-access policy change rather than a narrow cleanup row. |
| Access comes from an IdP-synced group | Check if Atlassian Administration marks membership as externally managed. | Route the change to the identity owner and keep the row open until sync is confirmed. |
| User access admin cannot grant or remove a role | Check whether the app's default group includes apps outside that admin's scope. | Escalate to an organization admin or adjust group design with approval. |
| User needs the app but not broad in-app access | Confirm the app role separately from project or space permissions. | Keep app access and route the permission change to the app admin. |
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:
- Using organization membership as if it proves paid app access.
- Removing an in-app permission while leaving the app role active.
- Ignoring groups that grant multiple apps at once.
- Assuming a user access admin can change every default-group path.
- Failing to verify identity-provider sync after an app-access removal.
Checklist
- Name the exact Atlassian app, site, and app role under review.
- List all groups that assign the app role.
- Identify default groups and any groups that grant more than one app.
- Separate direct app roles from group-based roles.
- Flag externally managed groups before planning removals.
- Confirm whether the request is license cleanup, security review, or both.
- Record owners, exceptions, and post-change verification.