In this article, we will describe the Sync Settings from User Sync Cleanup Behaviour and Scheduled Synchronization.
The Cleanup Behaviour is the last step in the full sync process and happens after all users have been synchronized from the 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 a member 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).
Our recommendation would be to check the options in your test environment before you do it in your production instance.
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 (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 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 reactivating 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.
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
- The email is changed to
- The full name is changed to
XXXis 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=trueis added to the user
Under certain circumstances, a deletion will not work. Please read the following Atlassian articles and verify, if a User deletion would work or not:
- Jira – https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html
- Confluence – https://confluence.atlassian.com/doc/delete-or-disable-users-138318.html
The Cleanup Behaviour is getting triggered every time a full sync is performed. The full sync can be triggered manually by clicking Sync on the main User Sync configuration screen, or it can be scheduled to run periodically. The Scheduled Synchronization can be configured below the Cleanup Method. We would recommend combining the Cleanup Behaviour with the Scheduled Synchronization. An active scheduled synchronization will make sure the above criteria are checked regularly, hence the chosen cleanup behaviour will happen to users accordingly.
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.
- 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.