How to Manage Inactive Users in Jira When You're Using SCIM Provisioning

[#1]

How to Manage Inactive Users in Jira When You're Using SCIM Provisioning

If your organization uses SCIM to provision users into Jira Cloud, you've already taken a serious step toward clean, automated identity management. But there's a gap that catches a lot of admins off guard: SCIM doesn't detect inactivity. Users who were provisioned months ago, stopped logging in, and never got removed from your IdP -- they're still sitting in your Jira instance, still consuming licenses, and still completely invisible to your SCIM integration.

This article breaks down what SCIM actually handles, where it stops, and what your options are for managing inactive users in a SCIM-connected environment without creating sync conflicts.

What SCIM Does (and Does Really Well)

SCIM -- the System for Cross-domain Identity Management -- is a protocol that lets your identity provider (Okta, Azure AD/Entra ID, Google Workspace, etc.) act as the single source of truth for user accounts. When you connect your IdP to Atlassian Guard via SCIM, you get:

• Automated provisioning: A new hire added to the correct IdP group gets Jira access without admin intervention.
• Attribute syncing: Display names, email addresses, departments, and job titles stay current.
• Deprovisioning on offboarding: When you disable or remove a user in your IdP, SCIM deactivates the Atlassian account and removes them from provisioned groups.

For organizations managing dozens or hundreds of users, this is a major operational win. You maintain one directory and Atlassian stays in sync.

The Gap: SCIM Is IdP-Driven, Not Activity-Driven

Here's where the problem starts. SCIM responds to changes in your identity provider. If nothing changes in the IdP, nothing changes in Jira.

An employee who left their team six months ago but was never removed from the relevant Okta group? Still provisioned. A contractor who wrapped up a project and stopped logging in? Still there. A user who moved to a role that doesn't require Jira access but whose account was never adjusted in the IdP? Same outcome.

SCIM has no visibility into what's happening inside Jira itself. It doesn't know whether a user last logged in yesterday or eight months ago. Inactivity detection needs to happen at the Atlassian product level, not the IdP level.

This is a meaningful distinction because your license costs are tied to active users in Atlassian, not user count in your IdP. Every inactive user who remains provisioned is a seat you're paying for.

The Unmanaged Account Problem Makes It Worse

There's a second category that SCIM can't touch at all: unmanaged accounts.

An unmanaged account is any Atlassian account whose email domain hasn't been verified by your organization. This typically applies to contractors, agency partners, and external collaborators who were invited directly to your Jira site rather than provisioned through your IdP.

Because these accounts sit outside your verified domain, they're outside SCIM's scope entirely. Disabling them in your IdP does nothing -- they weren't provisioned through SCIM in the first place. The only way to manage these accounts is directly through Atlassian administration.

This means most organizations are dealing with two distinct user populations that need different management approaches: managed accounts under SCIM control, and unmanaged accounts that require direct action in the Atlassian admin console.

Why You Can't Just Run SCIM Cleanup Through the IdP

A common instinct is to solve the inactivity problem by cleaning up the IdP -- remove inactive users from groups, disable accounts, and let SCIM propagate the changes. This works, but it creates two practical problems.

First, your IdP doesn't know who's inactive in Jira. Unless you're exporting Jira's last-login data and importing it back into your IdP (a manual process with real overhead), your IdP has no signal for Atlassian-specific inactivity. A user might be active in other applications connected to the same IdP while being completely dormant in Jira.

Second, deprovisioning in the IdP has broad consequences. Removing someone from an IdP group to cut their Jira access might also cut their access to other applications provisioned from the same group. You'd need per-application group management, which adds significant IdP complexity.

The cleaner approach is to handle Jira-specific inactivity at the Jira level, without touching the IdP at all.

Your Options for Managing Inactive SCIM Users

Option 1: Manual Audit via Atlassian Admin

Atlassian Administration at admin.atlassian.com provides last-login data under Directory > Users. You can filter, review inactive users, and deactivate accounts individually.

This works for smaller teams or periodic cleanup. For organizations with hundreds of users or a need for ongoing hygiene, it doesn't scale. Manual audits are also easy to deprioritize when other work piles up.

Option 2: Atlassian REST API + Scripting

Atlassian's User Management REST API lets you query last-login timestamps and programmatically deactivate accounts. Teams with scripting resources often build scheduled jobs that:

1. Pull all users with product access
2. Check last-login date against a threshold (e.g., 90 days)
3. Remove inactive users from product groups or deactivate their accounts

This approach is powerful and fully compatible with SCIM environments -- you're operating on the Atlassian side, not the IdP side, so there's no SCIM sync conflict. The tradeoff is that you need someone to build and maintain the script, handle edge cases (admin accounts, service accounts), and keep it running reliably. It's a reasonable solution for teams with engineering capacity, but it's not a set-and-forget answer.

Option 3: A Marketplace App

For teams that want automation without writing and maintaining custom code, there are apps in the Atlassian Marketplace that handle inactive user detection and deactivation directly within Jira and Confluence.

I work at the company behind User Management Automation for Jira & Confluence, which is one option in this category. It's a Forge-native app that covers both Jira and Confluence in a single install. Key capabilities relevant to this problem:

• Automatically detects inactive users based on last-activity date and deactivates them on a schedule
• Removes inactive users from product groups to revoke access without creating SCIM sync conflicts
• Handles unmanaged accounts that fall outside SCIM's scope -- the same interface manages both populations
• Provides audit logs so you have a record of every deactivation action

The SCIM compatibility piece is worth emphasizing: the app works at the Atlassian product level, so it doesn't interfere with your existing IdP configuration. Users deactivated through the app are deactivated in Atlassian, not in your IdP, which is exactly what you want when the inactivity is Jira-specific.

There are other apps in the Marketplace that address similar use cases. The right choice depends on your existing tooling, how much you want to configure vs. automate, and whether you need Confluence coverage alongside Jira.

A Few Practical Considerations Before You Act

Exclude service accounts and admin accounts from any inactivity-based automation. These accounts often show no "last login" because they authenticate via API tokens, not interactive login. Deactivating them by mistake can break integrations.

Define your inactivity threshold thoughtfully. Ninety days is a common starting point, but teams with seasonal projects or part-time contributors might need a longer window. Build in a review step or a warning notification before deactivation if your culture requires it.

Decide what "deactivation" means for your situation. Deactivating a user in Atlassian removes their product access and frees their license seat, but preserves their account history -- issue assignments, comments, and audit records stay intact. This is usually the right outcome. Deletion is permanent and harder to justify unless you have a specific data retention reason.

Document your approach. If you're using SCIM and also running inactivity-based deactivation through another method, make sure your team knows both processes exist. Overlapping automation can cause confusion when a user is deactivated from two directions simultaneously.

The Bottom Line

SCIM is the right foundation for enterprise user management in Jira Cloud. It handles the provisioning lifecycle reliably when tied to a well-maintained IdP. But it's not designed to detect dormant accounts, and it has no visibility into unmanaged accounts at all.

Filling that gap requires a separate process -- manual, scripted, or automated through a tool built for the purpose. The goal is to close the loop between how your IdP manages identities and how Atlassian assigns license seats. Done well, you get a user directory that reflects actual usage, not just onboarding history.

If you're running into this problem, you're not alone -- it comes up constantly for organizations at scale. Happy to answer questions in the comments about SCIM configurations, inactivity thresholds, or handling the unmanaged account edge cases.