If you have been managing Atlassian products for any length of time, chances are you have encountered ScriptRunner. It is one of the most installed apps on the Atlassian Marketplace, and for good reason -- it turns Jira and Confluence into highly customizable platforms where almost anything can be automated with Groovy scripts.
One common use case that comes up repeatedly in admin forums is using ScriptRunner to deactivate inactive users. It is technically possible, but whether it is the right approach depends on your team's scripting capacity, maintenance tolerance, and what you actually need from the solution.
This article breaks down both approaches -- ScriptRunner custom scripts and dedicated user management apps -- so you can make an informed choice.
The ScriptRunner Approach
ScriptRunner for Jira Cloud lets you write custom scripts that run on schedules, respond to events, or execute on demand. For user deactivation, the typical pattern is:
- Write a scheduled job that runs daily or weekly
- Query the Atlassian Admin API for user last-login timestamps
- Filter users who exceed your inactivity threshold
- Call the deactivation API for each qualifying user
- Log the results somewhere reviewable
This approach works. ScriptRunner is powerful, flexible, and if your team already has it installed for other purposes, the marginal cost of adding a user deactivation script is low.
Where ScriptRunner Works Well
Highly custom logic. If your deactivation rules are unusual -- different thresholds per department, exceptions based on custom user properties, integration with an external HR system -- ScriptRunner gives you the flexibility to encode any business logic you need.
Existing ScriptRunner investment. If your team already maintains ScriptRunner scripts for other automation, adding user management scripts fits naturally into your existing workflow.
One-time or infrequent cleanup. If you just need to do a single bulk deactivation rather than ongoing automation, a ScriptRunner script is quick to write and does not require installing another app.
Where ScriptRunner Gets Complicated
API limitations in Cloud. ScriptRunner for Jira Cloud operates within Atlassian Connect's sandbox. Accessing the Admin API for user management requires specific scopes and authentication that differ from the standard Jira API. Getting the right permissions configured is not always straightforward, and API changes can break scripts without warning.
Cross-product coverage. A ScriptRunner script in Jira only has native access to Jira data. If you want to check Confluence inactivity as well, you need separate scripts or more complex API orchestration. Managing inactive users across both products from a single ScriptRunner instance adds real complexity.
Maintenance burden. Scripts need an owner. When the person who wrote the deactivation script leaves the team, or when Atlassian deprecates an API endpoint, someone needs to debug and update the code. For a script that directly affects user access, a silent failure can mean months of paying for inactive licenses before anyone notices.
No built-in UI. ScriptRunner scripts run in the background. There is no dashboard showing which users are currently flagged as inactive, no preview of who will be deactivated on the next run, and no easy way for a non-technical admin to adjust thresholds or review audit logs without touching code.
Unmanaged accounts. Users with personal email addresses (not under your verified domain) are unmanaged accounts in Atlassian. The standard Admin API handles them differently, and ScriptRunner scripts that work for managed accounts often fail silently for unmanaged ones.
The Dedicated App Approach
Several Atlassian Marketplace apps are built specifically for user lifecycle management. These apps typically provide:
- A visual dashboard showing inactive users across products
- Configurable inactivity thresholds without coding
- Automated deactivation on a schedule
- Audit logs of all actions taken
- Support for both managed and unmanaged accounts
- Cross-product coverage (Jira and Confluence in one view)
Full disclosure -- I work on User Management Automation for Jira and Confluence, which is one app in this category. It runs on Forge (Atlassian's newer app platform where data stays within Atlassian infrastructure) and covers both Jira and Confluence in a single install.
Where Dedicated Apps Work Well
Zero scripting required. Configuration is point-and-click. An admin can set up inactivity rules, review flagged users, and activate automation without writing or maintaining any code.
Cross-product visibility. Purpose-built apps are designed to show user activity across Jira, Confluence, and other Atlassian products in a unified view. You can see at a glance which users are active in Jira but inactive in Confluence.
Ongoing automation with oversight. These apps are designed for continuous operation -- daily scans, automated deactivation, audit logging, and notification workflows. The automation runs reliably without manual intervention, but provides enough visibility that admins can review and override when needed.
Unmanaged account handling. This is a common gap that dedicated apps address explicitly. Unmanaged accounts require different API calls and different handling logic. Apps built for this use case handle both account types transparently.
Where Dedicated Apps Have Limitations
Less flexibility for custom logic. If your deactivation rules are highly specific to your organization, a dedicated app may not support every edge case. Most apps offer configurable thresholds and basic exception rules, but they will not match the arbitrary logic you can encode in a custom script.
Additional cost. Dedicated apps have their own pricing on top of your existing Atlassian subscription. For small teams, this may not be justified. For larger organizations, the time saved on script maintenance often pays for the app within weeks.
Another vendor dependency. Installing a third-party app means trusting another vendor with access to your user data. Look for apps that run on Forge (data stays in Atlassian) rather than Connect (data may be processed on the vendor's servers) if data residency matters to your organization.
Decision Framework
Here is a practical way to decide:
Choose ScriptRunner if:
- You already have ScriptRunner and a team comfortable writing Groovy
- Your deactivation rules are highly custom
- You only need Jira (not cross-product)
- You need a one-time cleanup, not ongoing automation
- You have engineering capacity to maintain the script long-term
Choose a dedicated app if:
- You want set-and-forget automation without coding
- You need cross-product coverage (Jira + Confluence)
- You have unmanaged accounts to handle
- You need audit logs and compliance reporting
- Your admin team is not comfortable with scripting
- You want a visual dashboard for user activity
A Hybrid Approach
It is worth noting that these approaches are not mutually exclusive. Some teams use ScriptRunner for custom Jira automations where they need full control, while using a dedicated app for the user management piece specifically. This avoids the maintenance burden of user management scripts while keeping ScriptRunner available for other automation needs where its flexibility shines.
Whichever approach you choose, the important thing is to have something in place. The cost of inactive users compounds monthly, and the security risk of dormant accounts grows over time. A working solution -- even an imperfect one -- is significantly better than a quarterly manual audit that keeps getting postponed.