Deactivating and Reactivating User

Deactivating and Reactivating Users without breaking assignments and mentions - Workflow for Atlassian Cloud

Terminology note: This page describes how to remove and restore product access for users using User Management and License Optimizer for Cloud (referred to as User Management for Cloud below). This is different from account suspension (which blocks all access across all Atlassian services) or account deactivation (performed via admin.atlassian.com). The app's bulk operations use the terms Remove App Access and Restore User Access for these workflows.

Overview

Atlassian Cloud organizations often remove users from product-access groups to save license costs, but doing this without preparation can break assignments and mentions. The User Management for Cloud app automates the removal of product licenses. The app provides a centralized dashboard for viewing, filtering, and managing users, groups, and permissions, and includes bulk operations and automated tasks.

The core principle: UCM only modifies product-access groups - the groups Atlassian uses to grant license seats (e.g. jira-users-{site}, confluence-users-{site}, confluence-guests-{site}). UCM never modifies your custom permission groups. So the recipe is: keep every permission grant (Assignable User, space access, project access) on a non-product-access group. Then UCM deactivation removes a user's license without breaking any of their assignability or visibility.

How to spot product-access groups in UCM: in the User Browser table, product-access groups are prefixed with # (e.g. #jira-users-cloud-ai-apps1). Custom permission groups (jira-member, hr-users, inactive-users) have no #. Bulk operations like Remove App Access only modify product-access groups.

This guide describes how to configure your organization so that:

Users are deactivated in Jira/Confluence for licensing purposes (no product seats are consumed).
They remain assignable and mentionable because they still appear in project and space permissions.
When the user signs in again via SSO, they are automatically reactivated because Atlassian’s App access settings automatically reassign them to a defined product role.

Prerequisites

Single sign-on (SSO) set up and enforced - your organization must use an identity provider (IdP) to authenticate users, and users should only be able to log in via SSO.
Managed domain verified - the company domain must be verified in your Atlassian organization.
User Management for Cloud is installed; this app removes users from product access groups based on inactivity.
Project/space permissions prepared - decide which roles or groups will keep users assignable when they have no license.

Configure an authentication policy that enforces SSO

Sign in to admin.atlassian.com as an organization admin.
Navigate to Security → User security → Authentication policies.
Click Add policy or edit an existing one. Check Enforce single sign-on under Authentication method. Then open the policy's Members tab and add the users this policy should apply to.

Automatically assign product access via approved domains

Atlassian’s App access settings allow you to specify default product roles for users from an approved domain. When a user from that domain signs in (via SSO), Atlassian automatically adds them to the product’s access group. This mechanism will later reactivate deactivated users.

From admin.atlassian.com, select Apps → App access settings.
Under Approved domains, click Add domain and enter your company domain (for example, example.com ).
Atlassian displays each product (Jira, Jira Service Management, Confluence, etc.). For each product, select a Role (usually User). In the Admin approval column, uncheck Required for products that should auto-provision without manual review. Leave the role as None for products you don't want to assign.

Atlassian App Access per domain

When Admin approval isn't required, users from this domain are granted product access automatically the first time they sign in. Reactivation works the same way: after User Management for Cloud removes a deactivated user's product access, their next sign-in re-provisions the license. With Admin approval Required checked, requests appear on User requests → Access requests and need manual approval.

Configure your organization so that product access groups are not provisioned directly from the Identity Provider (IdP) via SCIM or Single Sign-On (SSO) in this scenario. Instead, use placeholder groups in the IdP and implement a second layer with Automated Tasks in the User Management for Cloud app within your systems to manage final access assignments.

Deactivate users by removing product-access groups only

The User Management for Cloud app removes users from the group that provides product access when they are inactive for a defined period. Use the app’s automation to manage deactivation; alternatively, you can manually remove users (bulk actions) from the product access group in Atlassian Administration.

Do not remove the user from their project roles or space permissions groups during this step. Removing only the product access ensures the user no longer consumes a license.

Ensure unlicensed users stay assignable and mentionable

When a user loses their license, they can no longer log in, but other people can still assign them tasks or mention them if they remain in project or space roles. You must therefore assign them to a role or group with the right permissions:

Jira / Jira Service Management

The rule: to keep users assignable after license removal, every user must be a member of a stable group that is not a product-access group. Product-access groups change when UCM removes a license. Non-product-access groups stay intact - so any permission attached to them survives deactivation.

Which stable group should I use? It depends on how granular your permission model is:

Specific groups from your IdP (recommended for most orgs): e.g. hr-users, devops-users, finance-team. These are provisioned from your identity provider via SCIM and already match how your org organizes people. Use them as-is.
One holistic group for everyone: e.g. jira-member or all-employees. Simpler to maintain but less granular - everyone shows up in every assignment picker.
A dedicated deactivated-users group: e.g. inactive-jira-users, populated by a UCM Automated Task as part of the deactivation workflow. Useful if you want deactivated users visible in pickers but visually separated from active staff.

How to tell if a group is product-access or stable: in UCM's User Browser, product-access groups are prefixed with # (e.g. #jira-users-cloud-ai-apps1) and rendered in dark gray. All other groups are light gray - those are the stable groups you can safely use here. The only permission you need to wire up is Assignable User.

Once you have picked your stable group, add it as follows:

Company-managed projects (CMP)

Open the project, then Project settings → Permissions.
Edit the Assignable User permission in the Permission Scheme.
Add your group (e.g. jira-member).

Assignable User permission in a Company-managed project permission scheme

Team-managed projects (TMP)

Open the project, then Project settings → Access.
Add your group with the Member role.

The Member role in TMP already grants the same assignability rights as the Assignable User permission in CMP. Team-managed projects don't use permission schemes, so there's nothing else to configure here.

Don't confuse the Assignable User permission (users with this permission can BE assigned) with the Assign Issues permission (users with this permission can perform assignments). This workflow only needs the first one.

Confluence

UCM bulk operations and Automated Tasks treat the Confluence guest group as a product-access group. To keep deactivated users mentionable in Confluence without losing the guest group on the next deactivation, use this Automated Task recipe:

Automated Task recipe:

Remove App Access - select the Confluence product.
Add to Group - select your dedicated deactivated-user group (e.g. inactive-confluence-users). This group should hold Confluence space permissions so mentions keep working.

The Atlassian workflow lets Confluence users stay mentionable when they belong to the auto-provisioned confluence-guests-{site-name} group (the per-site guest group, e.g. confluence-guests-cloud-ai-apps1). Deactivated users are flagged as guests, which also affects automatic reactivation. Guests can access Confluence but not individual spaces. To regain space access, they click Request Space Access, which triggers the auto-provisioning workflow to restore product access. If mentionability isn't required, skip the guest-group step for a cleaner auto-reactivation.

Create a separate group for deactivated users and grant this group Confluence guest access (this is the per-site confluence-guests-{site-name} group).
Give guest Access to Confluence
For each space where you need to mention unlicensed users, go to Space Settings → Permissions.

Confluence Groups Permissions - Confluence.

By keeping deactivated users in these project/space roles or groups, you ensure they appear in user pickers and mentions even though they no longer have product access.

Heads-up: Remove App Access for Confluence also removes the user from confluence-guests-{site-name}. If you only set up the guest group for mentionability, deactivated users lose their mention visibility on the next pass. Use the Automated Task recipe above (or any flow that adds users to a non-product-access group AFTER removing app access) to keep them mentionable.

The following behavior was successfully tested.

App	Assign	Mention	Notification
Jira	yes	yes	just for mentioning
Confluence	N/A (Confluence has no assignee concept)	yes	no

Test reactivation via SSO

After a user has been deactivated, confirm that they no longer have the license. Go to admin.atlassian.com → Directory → Users → click the user → Groups tab. The Apps column on each group row shows how many products that group grants access to - this is how you spot which groups carry license seats. The deactivated user should not be a member of any product-access group.

Cloud App User Management - Test reactivation via SSO.

In Jira, try assigning an issue or page mention to the user. You should still see their name in the picker, confirming that project/space permissions are working.
Ask the user to sign in via your IdP. When they authenticate through SSO, Atlassian detects their email domain and automatically assigns them to the product role you configured in App access settings. This adds them back to the product access group and reactivates their license. They can now log in normally.

Additional notes

Different products and roles: The Role in the App access settings corresponds to the product’s access level - for example, “User” for Jira or Confluence. If your organization uses different access levels (e.g., “Basic” vs. “Trusted”), assign the appropriate role for automatic provisioning.
Multiple domains: You can add several approved domains. Each can have its own default roles and admin-approval requirements.
User Management for Cloud automation: The app includes features to deactivate Product Access. The reactivation process is managed solely using existing features within the Atlassian platform and is not managed through the User Management for Cloud app.

Performing Bulk Operations - Bulk suspend and restore users
Searching and Filtering - Find inactive users
Creating Automated Tasks - Automate deactivation workflows
Groups & Access Control in Atlassian Cloud - Manage group memberships