Route an Atlassian cleanup case out of local admin work when the durable decision belongs to an IdP owner, HR owner, security owner, app owner, project owner, or privileged-access approver rather than the Jira or site admin who found the issue.
Why this matters
Good cleanup is not always local action. Sometimes the right outcome is a clear handoff with evidence. Routing out prevents local admins from making identity, employment, security, or technical-owner decisions they do not own.
For the query externally managed access cleanup 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 monthly access review finds a stale user in Jira, but the row is part of a SCIM group, has a service-account naming pattern, and holds a project-admin role. Removing access locally would be fast, but the correct path is identity, technical owner, and privileged-role review.
Route out when ownership is external
If a group or user is controlled by the IdP, local Jira admins should provide evidence and send the change to the identity owner. The cleanup record should show that the case was routed, not ignored.
Route out when the account is non-human
Service, automation, app, and integration identities need technical-owner review. Local removal without dependency checks can break jobs, imports, notifications, or API integrations.
Route out when privileged access is involved
Org admin, site admin, Jira admin, and project admin roles should follow privileged-access approval. They should not be removed or retained inside a generic stale-user cleanup batch.
Route out when policy decides the outcome
Some cases need HR, security, legal, or business-owner decisions before the admin acts. Preserve the technical evidence and make the policy owner explicit.
Make route-out evidence actionable
A good handoff includes the access path, affected users or groups, why local action is not appropriate, requested decision, owner, due date, and next review status.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Membership is IdP-owned | Confirm SCIM sync, read-only state, and identity owner. | Route to IdP owner with group and access-impact evidence. |
| Account appears non-human | Check integration purpose, technical owner, token use, and automation dependency. | Route to technical owner before removal. |
| Privileged admin role is present | Confirm role type, business need, and last approval. | Route to privileged-access approver with evidence. |
| Employment or contract status is unclear | Check HR or vendor owner before treating the account as stale. | Route to business owner or HR process before access removal. |
| Project owner disputes cleanup | Capture project role, permission scheme, and business impact evidence. | Route to project or business owner and set a review deadline. |
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 routed cases as unfinished rather than correctly owned.
- Making local changes that an IdP sync will reverse.
- Removing non-human accounts without technical-owner approval.
- Letting privileged roles ride along in ordinary cleanup.
- Sending owners vague cleanup requests without access evidence.
Checklist
- Decide whether the local admin owns the actual change.
- Identify identity, HR, security, app, technical, or project owners where relevant.
- Attach the access path and cleanup reason to the handoff.
- Separate route-outs from local approved removals.
- Give each routed case a deadline and next review status.
- Keep the route-out visible in the review evidence.