.Deactivate and Manage User Accounts
A deactivated user doesn’t count against your organization’s available Atlassian user licenses. However, deactivating a user doesn’t immediately reduce the number of licenses for which your organization is billed. To change your billing, you must change the current user tier.
Deactivating users can, however, prevent you from having to jump to the next user tier which can be caused by a combination of reasons:
users get Atlassian accounts they don’t actively need
users that leave the organization or change roles don’t have their accounts deactivated in a timely manner
From the 15th of February 2022, Atlassian does not even allow you to up or downgrade your user tier license for Server products which makes it even more important to only have the active accounts on your application that are really needed.
As you can see, deactivation is an essential piece of user management. Failing to deactivate Jira users can have very negative consequences, like exceeding license limits or maintaining access from former employees – a major security concern.
User Sync is one of our user provisioning methods that can be used when you maintain your company user accounts in a Cloud Identity Provider. It comes with a variety of features that help you to maintain your user base. Multiple Cloud Identity Providers are supported by us.
For some methods, you would need to run our plugin SAML Single Sign On with a version > 6.x.x (User Sync > 2.4.x). We did not add version compatibility to every method, so our recommendation would be to use the latest SAML SSO / User Sync version.
Cleanup Behavior
The Cleanup Behaviour is the last step in the full sync process and happens after all users have been synchronized from the Cloud Identity Provider (IdP). The remaining users that already exist in the User Sync directory but were not returned by the IdP anymore will be handled according to the chosen Cleanup Method. A user will not be returned by the IdP anymore, because:
They get deleted in your IdP (e.g., Azure AD) → e.g., they left the company and the IdP-Team deleted the user
they are not members of any required groups anymore → Required Groups
they are dropped by a transformation in the attribute mapping → Group Transformations
With default settings, these users are deactivated (disabled).
For more information and instruction on how to configure, please visit Cleanup Behaviour and Scheduled Synchronisation.
Cleanup inactive users - Connector
With the Cleanup Inactive Users connector, you can as an example deactivate users that have not logged in for a certain amount of time. One very strong use case where the connector can help is when you use Just-in-Time provisioning as your user provisioning method. Using this method you have no way to provide the information to your application that a user was deactivated or deleted on the Identity Provider side. The Cleanup Inactive Users connector helps you reduce the number of users on your Atlassian license.
In case a user was deactivated due to long inactivity but still requires access to your application, you can automatically activate the user account again upon SSO login. You find the configuration in our SAML Single Sign On plugin → Identity Provider → User Creation and Updates and it is activated by default. Using the combination of the Cleanup Inactive Users connector in User Sync and the feature in our SAML Single Sign On plugin results in a seamless experience for your users and cost savings for your instance.
For more information and instruction on how to set this connector up, please visit Cleanup Inactive Users Connector Configuration.
Excel Connector
The Excel connector is a custom connector for User & Group Sync. You will find more information in our extra article Excel Connector
If you want to disable users, you need to modify the following attribute ATTR_ACTIVE. All users with the flag 'false' will be disabled (of course, you would need to use the Import Users from Excel Connector and import the modified Excel file).

Groovy Connector
The Groovy Script will compare users in the IdP directory with users in the internal directory, and if they match, it would disable the matched users in the internal directory.
First, go to User Sync and click on Create New Groovy Connector. Please add the following Groovy Code:
- class ConnectorCode extends GroovyConnectorCode {
- long connectorDirectory = 10600
- long internalDirectory = 10601
- @Override
- void sync(SyncWrapper sync) {
- RemoveDuplicate removeDuplicate = new RemoveDuplicate()
- atlasUserAdapter.applyToAll(
- internalDirectory,
- removeDuplicate,
- sync.getSyncStatus())
- }
- class RemoveDuplicate implements AtlasUserFunction {
- Optional<AtlasUserResult> apply(AtlasUser atlasUser, AtlasUserStatusObject status) {
- String username = atlasUser.get('ATTR_NAME').get()
- if(!atlasUser.isActive()) {
- logger.warn("$username is already inactive")
- status.add(notModified(atlasUser))
- return Optional.empty()
- }
- AtlasUserResult findResult = atlasUserAdapter.readFirstUniqueUser(
- AtlasUserReference.create(
- AtlasUserKeys.ATTRIBUTE_USERNAME,
- username,
- connectorDirectory));
- if(findResult.isNotFound()) {
- logger.warn("$username is not in Connector-directory")
- status.add(notModified(atlasUser))
- return Optional.empty()
- }
- if(!findResult.isSuccess()) {
- logger.warn("Searching $username failed!")
- status.add(notModified(atlasUser))
- return Optional.empty()
- }
- // Use This for disabling:
- AtlasUser userToDisable = new AtlasUserBuilder()
- .findBy(atlasUser.getReference())
- .active(false)
- .build()
- AtlasUserResult result = atlasUserAdapter.update(userToDisable)
- status.add(result)
- return Optional.of(result)
- }
- }
- AtlasUserResult notModified(AtlasUser atlasUser) {
- return AtlasUserResult.builder(atlasUser.getReference())
- .operation(AtlasUserResult.Operation.NOT_MODIFIED)
- .inputUser(atlasUser)
- .build()
- }
- }
Adjust the directory IDs at the beginning of the script.
- long connectorDirectory = <id> // Id of the UserSync directory
- long internalDirectory = <id> // Id of the internal directory
After that, you need to set the working directory when you scroll further down.

This is going to be your internal directory, as the groovy connector uses this as a working directory to compare if users from the internal directory exist in the User Sync directory. When a user exists in both directories, then the user in the internal directory will be disabled.
As the last step, you need to save the configuration and run the Sync on the new Groovy connector. In the Sync Settings of the connector, you could also enable periodic Sync, so this script could also run periodically.
Filter the user
Filter the user is an option from the What should happen if no transformation applies menu, which you can configure if you add a Regex and Replacement Option (Attribute Mapping).

The user will be filtered if no transformation rule is applied. In the context of User Sync, the user will not be synced, or the cleanup behavior is applied if the user existed already.
Sync Single User
When the user is not found in the connector during a Single User Sync, an existing user can be disabled (as an example, the user is not a member of a required group anymore). This option is not done by default, the option Disable User if not found needs to be enabled in the Connector settings.
Please go to your User Sync Connector → Edit → Sync Settings and enable the option Disable User if not found. Depending on your needs, you would need to configure the Lookup Attribute Name and Attribute (as sent by Connector), too. Don't forget to Save and Return your Connector Configuration.

We have an article with further information https://wiki.resolution.de/doc/usersync/latest/knowledge-base/disable-users-not-found-in-the-connector
Product Placement
Maybe it's worth checking our License & User Deactivator app (https://wiki.resolution.de/doc/user-deactivator/latest/all) 🙂. Here are just some highlights, which could be helpful to achieve your goal:
User Deactivator helps you keep your user directory clean of inactive users!
Automatically deactivate multiple users on a scheduled basis
Automatically remove users from groups on a scheduled basis
Receive reports when users are deactivated
Exclude members of specific groups from deactivation or group removal
Filter users on last activity date and deactivate manually
By running User Deactivator, you ensure that your user directory reflects the actual active users.
License Optimizer is new functionality introduced with version 4.6.0.
Users are automatically removed and added again to the group providing application access to Jira or Confluence. This enables you to only consume the same amount of licenses as currently active users