Separate human and non-human accounts before an Atlassian access review by classifying employees, contractors, external collaborators, app users, service accounts, automation accounts, and integration identities into different review lanes with different owners and evidence.
Why this matters
Inactive-user cleanup becomes dangerous when service accounts and automation identities are treated like departed people. Human accounts need business-owner approval; non-human accounts need technical-owner validation and dependency checks.
For the query service accounts access review 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 stale-user export includes former employees, contractors, a Jira automation user, a marketplace app user, and an API integration account. Removing every inactive row would break workflows, but leaving the whole list untouched wastes licenses and weakens review credibility.
Classify before applying inactivity rules
Last activity is a useful signal for humans, but it is not a complete removal rule. Non-human accounts may look inactive while still supporting integrations, imports, workflow automation, or API access.
Give each lane a different owner
People usually need manager or business-owner approval. Service accounts need technical owners. App-related identities may need the app owner or vendor context. Identity-synced accounts may need an IdP owner.
Review product access separately from purpose
A non-human account can still consume product access or sit in a default group. Confirm both the access path and the technical purpose before keeping or removing it.
Use held-out status deliberately
Holding out a service account is valid only when the record says who owns it, what dependency exists, and when it will be reviewed again. A vague exception just recreates the same risk next month.
Build a cleanup-safe naming and owner model
Useful naming conventions, owner fields, and expiration dates make future reviews faster. The goal is not perfect taxonomy; it is enough structure to avoid breaking important non-human access during cleanup.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Employee or contractor account | Confirm manager, employment status, access path, and current business need. | Send to business-owner approval or offboarding lane. |
| Service account | Confirm technical owner, integration, token use, and removal test. | Hold out of human cleanup until the technical owner approves action. |
| Marketplace app or app-created user | Confirm app purpose, permissions, and whether the identity is managed by the app. | Route to app owner or vendor-aware review instead of ordinary user removal. |
| Automation account | Confirm scheduled jobs, workflow rules, API use, and audit trail requirements. | Document dependencies and remove only after a safe replacement or retirement plan. |
| Unknown account type | Check naming, email domain, groups, recent activity, and likely owner. | Move to investigation lane rather than approving immediate cleanup. |
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:
- Removing every inactive row from a stale-user export.
- Letting service accounts stay forever without a technical owner.
- Assuming non-human accounts never affect license cost.
- Mixing app-created identities into human offboarding.
- Recording exceptions without purpose or review date.
Checklist
- Create separate review lanes for human, contractor, external, service, automation, and app identities.
- Check product access for every lane.
- Assign business owners to human access and technical owners to non-human access.
- Keep service accounts out of bulk stale-user removal.
- Document held-out reasons and next review dates.
- Route externally managed rows to the identity owner.