The Cleanup Inactive Users connector helps you reduce the number of users on your Atlassian license. Starting from User Sync version 2.11 and SAML SSO version 6.8, the Cleanup Inactive Users connector offers enhanced flexibility. Apart from deactivating users based on the last login duration, you can now specify conditions based on group membership. Users can be deactivated if they are members of a specified group, or if they belong to groups that match a provided regex pattern. These group-based conditions can be used independently or in combination with the last login criteria.

Using this connector, for instance, allows you to deactivate users who haven't logged in for a set period. This is especially beneficial when using Just-in-Time provisioning, as it doesn't relay information about user deactivation or deletion from the Identity Provider to your application. Leveraging this connector helps optimize the number of users on your Atlassian license.

If a user is deactivated due to inactivity or group membership but later requires application access, they can be seamlessly reactivated during SSO login. This setting is available under the SAML Single Sign On plugin at Identity Provider → User Creation and Updates, and is enabled by default. Pairing the enhanced Cleanup Inactive Users connector with our SAML Single Sign On plugin ensures a smooth user experience and cost efficiency 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, where you can edit the connector's name and select the directory for this connector.

Note: If you choose a directory that is synchronized from User & Group Sync, disabled users will be reactivated upon the next synchronization. You can only pick internal directories.

You can now set up the conditions when a user should be cleaned up. 

Days since last login

Decide on the number of days since the last log-in to classify a user as inactive.

Groups to always cleanup

Specify which user groups should be considered for deactivation. This criterion can operate independently or in conjunction with the time-based inactivity metric.

Handling Users Who Have Never Logged In

Determine if users who have never accessed the system should be deactivated. By default, this option is unchecked, ensuring these users aren't automatically deactivated.

As the next step, you can now set the Cleanup Action.

Here, you see the different Cleanup behavior options. The default is to disable users, which is a suitable method for almost all use cases. Nevertheless, please see below the different options.

• 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 (IdP and local) 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. As soon as the option is enabled, you have the possibility to add groups or regex matching groups, which will NOT be removed during cleanup.

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.