Introducing Bulk User Actions
Administrators of Atlassian apps like Jira, Confluence, or Bitbucket are used to managing users one by one. However, bulk user operations can apply an action to any number of users in a matter of seconds.
In case you’re wondering what bulk actions for managing Atlassian users potentially exist, here’s a full list:
- Bulk User Creation
- Bulk User Activation / Deactivation
- Bulk User Deletion
- Bulk User Update
- Bulk Add user(s) to group(s)
- Bulk Remove user(s) from group(s)
Managing access policies
Of all the bulk operations above, some are more interesting than others:
- Activation and Deactivation allow user to login (authenticate) versus a user that won’t be able to log into the application.
- Group memberships are tightly related to permission schemes.
Let’s have a look at 4 examples of what you can accomplish when you install resolution’s User Deactivator to combine these essential actions with a powerful user browser.
Keep reading: A User Browser comparison: Jira vs Confluence vs Crowd vs User Deactivator
Use case 1: Bring a project team back to life
Imagine you have a specific project for your financial auditors, which work at your offices for a couple of weeks a year.
When the audit is over, you can deactivate the users in bulk.
You can simply:
- search for the project group “Financial Auditors”
- identify only the temporary contractors by excluding other groups
- or manually select the contractors’ records, as is the case here
- finally, deactivate the contractors in bulk
Next time you have a similar project and call those guys back, you can find the group, select only the auditors that are going to be in the team again, and activate them in bulk. For example, in this case Dan Ariely couldn’t make it because he’s writing his upcoming book on price anchoring.
Use case 2: Find who’s really inactive… and deactivate them
If you’ve ever used Jira’s user browser to find active users, you have experience dealing with false positives. Many of the users who have an active status can actually be inactive… they simply haven’t been deactivated.
With User Deactivator you can identify those false positives. Simply use this filter:
- find users with status active
- filter by those users who haven’t had activity in the period of your choice (for example, the last 6 months)
- And deactivate them in bulk!
Remember: If you use Just-in-time provisioning through SAML SSO, those users will be reactivated whenever they try to log in again.
Use case 3: Monitor and assign project resources based on activity
There are very interesting possibilities if your company decides to create groups for your Jira projects (or at least, for the most important ones), instead of running project membership based only on project roles.
Use a simple activity filter and:
- Find employees who are not members of any project group. These are candidates for joining new projects.
- Find project members who have an active status but haven’t had any activity in a long time
- List members of the project who are actively using Jira
Change project with space, and similar rules can apply to Confluence power contributors.
Use case 4: Corporate schemes
When a branch of an enterprise is sold to a different company, users can be filtered by the branch’s domain and deactivated in bulk.
Bonus search: Check admins status
Other interesting use cases of User Deactivator don’t necessarily involve bulk actions. Our clear favorite is to obtain a comprehensive list of administrators.
Note: While you can create these lists in Jira out of the box, it’s not possible in Confluence or Bitbucket. That’s where User Deactivator comes in handy.
Those lists can be broken down further and be an important part of an audit. For example, a list of all active administrators with their activity stats can help identify who doesn’t need an administrator role; on the contrary, a list of disabled admins can also be convenient to understand which groups need more admin coverage.