This guide demonstrates how to efficiently suspend a specific subset of Atlassian users based on precise filter criteria like app access and email domains in under five minutes. By utilizing bulk operations instead of manual spreadsheets, you can ensure security compliance and clean user management without the risk of administrative errors.
Our approach streamlines complex contractor offboarding or security event responses by using a controlled, filter-based safety net for administrative scale.
Watch our step-by-step walkthrough in our video to see this process in action within the Atlassian interface.
The Reality of Administrative Overload in Atlassian Cloud
In our video, we address a common struggle for IT admins: the request to suspend a very specific group of users without affecting the rest of the organization. We often see admins buried under spreadsheets, clicking through hundreds of individual profiles to verify access levels. This manual approach is a recipe for what we call “big admin weekends,” where a supposedly small task turns into a lengthy recovery project due to human error or outdated data.
We believe that targeted filters are the ultimate safety net for any administrator. When you are tasked with offboarding contractors or responding to a security event, the goal is to be fast and consistent. By using the methods we outline, you can transform a tedious afternoon of manual clicks into a five-minute task. Our technical support engineers at re:solution GmbH spend their days preventing these inefficiencies, ensuring that your user data remains clean and your security posture stays strong.
Critical Distinctions: Suspend User vs. Remove App Access
Before clicking any buttons in the admin UI, it is vital to understand the difference between two actions that are frequently confused. In our video, we emphasize that removing app access is not the same as suspending a user. Removing access simply detaches the user from a specific product like Jira or Confluence, but the account remains active in the system. While this might save on seat costs, it does not fully block access across the entire Atlassian service suite.
On the other hand, suspending a user is a much stronger and more immediate action. This is the “stop access now” operation. It completely blocks the user from all Atlassian services, invalidates their active sessions, and stops any automated integrations they might own. In this tutorial, we focus on suspension because it is the most effective way to handle high-stakes scenarios like contractor offboarding or security remediation where you need a hard stop on all user activity.
Step 1: Eliminating Stale Data with a Manual Sync
One of the biggest “gotchas” for Atlassian admins is relying on stale data. If a user’s access status changed just a few minutes ago, your current view in the admin portal might not yet reflect those changes. Running a bulk operation on outdated information can lead to suspending the wrong people or missing those who should have been included. This is why we recommend a manual sync as your first step.
We treat this sync as a “trust reset.” By navigating to the User Browser and initiating a fresh sync, we ensure that every filter we apply later is working against the absolute latest state of our user directory. While the sync runs, you can see the progress of the steps involved and how long it will take. Waiting those few extra seconds provides the data integrity necessary to perform bulk actions with total confidence.
Step 2: Configuring Targeted Filters
Once your data is fresh, the next phase is to build a multi-layered filter. In our example video, we look for a specific subset: users who have Jira access, but no Confluence access, and belong to a specific email domain. This level of granularity is what allows you to target contractor groups or specific departments without the need for external spreadsheets.
- Filter Criteria 1: We select “Included Apps” and set it to Jira. This isolates everyone who currently consumes a Jira seat.
- Filter Criteria 2: We use “Excluded Apps” to select Confluence. This narrows the list down to users who have Jira but lack Confluence access.
- Filter Criteria 3: We filter by the email domain, such as “azureadlab.resolution.de.” This ensures we are only targeting the specific external domain requested by the security or HR team.
By combining these three filters, we create a highly specific list of users. This is the moment to review the table for any surprises. Perhaps you notice a service account that shouldn’t have Jira access, or a user who should have had Confluence. This review phase is where you catch anomalies before they become permanent changes.
Step 3: Executing the Bulk Suspension Operation
After verifying the filtered list, we move to bulk operations. It is important to note that organization administrators are generally protected from these bulk actions; the system is designed so you don’t accidentally lock out the people who have the power to fix administrative mistakes. You can select all relevant users at once or pick specific individuals from your filtered results.
When you select “Suspend User” from the bulk action list, you must read the warnings like an engineer. This action is powerful: it ends active sessions immediately and invalidates API tokens and OAuth tokens. If these users have running automations or integrations, those workflows will cease to function the moment the bulk job completes. However, because suspension preserves user data and group memberships, you can rest easy knowing that reactivation will restore their previous access state perfectly if needed.
Step 4: Verification and Future-Proofing
Once the bulk operation finishes, we verify the results using the bulk results log. This log provides a clear audit trail of who started the job, whether it was successful, and exactly which users were affected. In our video, we confirm that the status of our targeted users has changed to “Suspended” directly within the User Browser interface. For ultimate peace of mind, we suggest a spot check by asking a suspended user to attempt a login; they should find it impossible to enter the system.
To make this process repeatable, we recommend saving your configured filter. This is incredibly useful for recurring tasks like quarterly offboarding or monthly security audits. You can even turn these saved filters into automated tasks that run without manual interaction. Finally, we advise creating a runbook in your company wiki and performing a “tabletop test” with a couple of test accounts to ensure your team understands the reactivation behavior and can handle future requests with the same speed and precision.
By following these steps, you ensure that your Atlassian environment remains secure and well-governed while reclaiming the time you would have otherwise spent on manual data entry.
