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.

Since User Sync version 2.1 (SAML SSO 5.1) the connector is called Cleanup Inactive Users connector and not Disable Inactive Users anymore. The name change was done to reflect the features (the possibility to configure different Cleanup Behaviors). 

Admins and Sysadmins will not be deactivated.

Cleanup Inactive Users connector configuration

  • Navigate to the User & Group Sync configuration page and add a new Cleanup Inactive Users connector.


You will be in the Cleanup Inactive Users Specific Settings section, now you can edit different settings.

    1. Choose a directory in which to disable inactive users
    2. Choose after how many days (since the last log-in) to mark users as inactive
      1. Note: If you choose a directory that is synchronized from User & Group Sync, disabled users will be reactivated upon the next synchronization.
    3. Decide if users that have never logged in should be disabled or not. By default, this option is not checked.


Next to Cleanup Inactive Users Specific Settings you should have a look at Sync Settings. Here, you see the different Cleanup behavior options. The default is to disable users which is the suitable method for mostly all use cases. Nevertheless, please see below the different options.


User Sync gives you the possibility to do the following cleanup behaviors:

  • Disable Users
    Users get deactivated, just like Atlassian recommends. Doing this saves licenses and retains the ticket history, as the user still exists.
  • Delete Users
    Users get deleted. We do not recommend this option, which has important consequences, e.g., for assigned tickets or user comments.
  • Anonymize Users (reversible)
    Username, email, and full name are anonymized. Since the Cleanup Inactive Users' user ID is still assigned to the users, this can be undone to rename users with their original names.
  • Keep Users Without Modification
    Users are not changed by the cleanup behavior.

Additionally, we support removing all group memberships of a user during cleanup. This will also apply to users that have already been cleaned up. This is available to Disable, Anonymize, and Keep Users Without Modification. The option is available to Disable, Anonymize, and Keep Users Without Modification. As soon as the feature was enabled, you have the possibility to add groups or regex matching groups, which will NOT be removed during cleanup.

With the option Use Groovy to decide about cleaning up a user, you can use a Groovy script to decide whether a user should be cleaned up or not. For more details, please read this article.

For Bitbucket, we recommend using Keep Users Without Modification and Remove group memberships during cleanup since the Bitbucket user browser does not allow to reactivate users via the UI. Usually, this is not a problem because the user will be reactivated during a Saml login. However, if that is not the case, then you need to reactivate the user via the database.

The default behavior is to disable users (as Atlassian recommends). When you change the cleanup behavior, you will need to do a Save and Return. This will save and enable the new configuration. If you run a full Sync, the new cleanup behavior will be used and affect all matched users.

Additional Information 

Anonymize Users (reversible)

This feature is available from SAML Single Sign On version 5.2.1 or later or User Sync version 2.2.1 or later. Already disabled users will also be anonymized. 

The user anonymization in User Sync currently works as follows:

  • The user will be renamed to user-XXX 
  • The email is changed to user-XXX@user.anon 
  • The full name is changed to user-XXX 
  • XXX is a random string of 10 numbers or lowercase characters
  • All other attributes, except user, email, and full name, are not touched
  • The user will be deactivated
  • The flag ATTR_IS_ANONYMIZED=true  is added to the user

Delete Users

Under certain circumstances, a deletion will not work. Please read the following Atlassian articles and verify, if a User deletion would work or not:

Using the Scheduled Synchronization makes the connector run periodically. That way everything runs automatically in the background:

Please switch the toggle Scheduled Synchronization to enable or disable the regular schedule. Now, you can edit the Cron Expression, which will define when the next sync will run. You can also decide how many sync results should be kept Results to keep (older results will be removed when a new sync starts). You can change it to a value, which match the customer requirement (there is no limitation from User Sync. The configuration field is an int (data type), so the limitation from the system is usually 2147483647).

Please keep in mind, that too high values (resultsToKeep) can lead to an impairment of the performance (database).

If you click on the pencil to edit the Cron Expression, you can use the Cron Expression Builder

Or, if you want, you can add a Cron Expression directly.

After you change the Scheduled Synchronization, you need to do a Save and Return. This will save and enable the new configuration.

Please note:

  • Synchronization time differs based on your user base
    • small instance (up to 1,000 IdP Users) runs a full sync once an hour
    • larger instances (up to 10,000 IdP Users) runs a full sync once a day (overnight)
    • enterprise instances (more than 10,000 Users) runs a full sync once a week
  • Our SAML SSO plugin will always do a Single User Sync. So, if the user does not exit, the user will be added or modified.
  • The full sync is more or less just to make sure we can disable deleted users and to make sure everything is fresh up with information.

If you run into problems, do not hesitate to contact our support.