Where To Find

Jira

Navigate to the User Management section and click on User Deactivator:

Confluence

In the administration section, scroll down to USERS & SECURITY and click on User Deactivator: 

Bitbucket

Click on the Admin cogwheel icon in the upper right corner and select User Deactivator from either the Accounts section in the left panel or the overview page itself:

Bulk User Operations

Filtering Users

As pictured below, you can change multiple filter settings (1) to retrieve users (3) you want to deactivate, reactivate or remove from groups.

These filters are:

• Time Since Last Activity

• Use Last Login As Last Activity (Jira only, please read the paragraph below “Cached Results” on this page)

• User Status (as in user is enabled/ active or disabled/ inactive or any of these two)

• In Group

• Not In Group

• Application Access

• Directory

• Search in Full Name, Username and Email

Improved User Search

The following option on the Misc Settings tab enables an improved search algorithm. It is only helpful if your Atlassian instance has multiple user directories.

The option does not affect the search in the Auto Deactivation and License Optimizer feature. Please refer to the part of the documentation that explains those options.

Cached Results

You can permanently disable the result cache (2) if required, for example, when working in an instance with frequent changes to user records. Example: A user gets removed from a group while you filter for users in that group. Only with the cache disabled would the user disappear from the result list when the filter is rerun.

Cached Results Default Setting

Navigate to the Misc Settings tab and change the corresponding setting. You need to reload the page after saving the setting to see it in the Bulk User Operations tab.

If you leave the result cache enabled and a user has been deleted or renamed in the meantime, you'll see a text instead of the username:

Use Last Login As Last Activity

This is available in Jira only. If you are using Jira as a user server in Confluence or Bitbucket, and a user logs in to Confluence or Bitbucket, the last activity is also updated in Jira and thus not correct. The example shows a user who recently logged in to Confluence, but in Jira, he hasn't been active since December last year.

Directory Mode

The colour assigned to the user's directory indicates whether the directory is in read-only mode (red). In a setup like this, you won't be able to deactivate these users.



Usually, only removing users from groups would work with this type of directory configuration, provided the groups are not already assigned to the user through that directory. An example would be a Microsoft Active Directory in Read-Only, with Local Groups mode, which you've configured to assign a group to the user on the first login. That group could then be removed from the user. The below screenshot shows a Microsoft Active Directory in that mode, where the group jira-software-users is assigned locally to the users if they first log in:

Per-User Actions

You can

1. Edit

2. Disable/ Deactivate

3. Delete

users from the actions column in the result list on the Bulk User Operations results:

For bulk operations, follow the instructions below.

Select Users to be Modified

Click the checkboxes of the users you want to bulk operate on, and click on Choose Bulk Action
You can also use the Select All button to select all the users matching your filter criteria.

Choose Bulk Operation

Pick one of the bulk user operation types and click on Next

Pick one of the bulk user operation types and click on Next

Confirm your Choice

Confirm your selection, and you'll see a summary of the operation to be executed:

Confirm your choice

Wait for the operation to complete

Wait for the operation to complete

Reviewing the Result

The result screen will show a summary of the operation again.

Reviewing the Result

Unsuccessful Login Attempts

This allows you to view inactive/ disabled users who have attempted to log in again. This will give admins a better overview of whom they might want to reactivate again. The tab contains all the functionality from the Bulk User Operations tab, you can refine the filter, and perform single-user actions or bulk operations similarly.

Automatic User Deactivation

Schedule

User Deactivator can be configured to automatically deactivate users or remove them from groups instead. To schedule automatic deactivation, click on the "Automatic User Deactivation" tab and use the scheduler component:

Please note that the schedule is saved in the server's time zone, where your Atlassian instance is running. “Next run” shows the converted value already in the time zone of your user profile.

Inactivity Period & User Account Expiration Emails

Configure a rule that instructs User Deactivator to automatically deactivate users who have not been active for a specified period, such as one month (1). If you want to send emails to the users to inform them about their upcoming deactivation, please use options (2) and (3). You can adjust the email content using the template editor described at the end of this page.

Deactivation Mode

If User Deactivation Mode (1) has been set to "Remove Users from Groups" and one or more group names have been selected (2)...

• Users will be removed from these groups, rather than being deactivated.

• This feature is specifically intended for users who manage users of, for example, Confluence via their Jira directory.

• You could remove users from all groups starting with "jira" and "confluence" and would revoke their access for both Atlassian platforms that way.

  • This would then also save Confluence licenses.

  • Please be aware that this is a specific setup of Jira/Confluence with Crowd; it does not automatically apply to all Jira and Confluence installations.

• Select one or more group names whose members would be excluded from deactivation or group removal (3)

  • exclude groups overrule the "Groups to remove", should you (accidentally) provide the same group names in both

Force Destructive Operations

Users will never be automatically deactivated or removed if they are a system administrator or administrator. Other default restrictions can be overridden with the checkbox to also process the following users:

Remove autoGroupsAddedAttribute

For more information about this feature, please refer to this knowledge base article.

Reporting

At the bottom of the page, you can add one or more email addresses to receive a report about the users modified during auto-deactivation. If none is provided, no summary report will be emailed. No mail will be sent if nobody has been deactivated or removed from groups.

A second table in the report would indicate whether some users couldn't be deactivated due to an unexpected error.

Email Template Editor

Since version 6.2.0, you can adjust the email via the template editor. The syntax is HTML with Apache Velocity. Below the editor window, a list of variables that you have access to is shown. You can validate your changes to it by using the "Send Test Email" button. This requires you to have a valid address assigned to the account with which you are logged in. It also works if the automatic deactivation is not enabled. Don't forget to set the "User Deactivation Mode" according to your needs before, as it defines which content will be displayed (see lines 16 and 18 in the default template for reference).

Below are two examples of how the emails look with the default template.

Warning about being removed from groups

Warning about being deactivated

Microsoft Active Directory

The table below explains the differences in behaviour when using User Deactivator on users in a Microsoft Active Directory.