Deactivating and Reactivating User

Deactivating and Reactivating Users without breaking assignments and mentionings – Workflow for Atlassian Cloud

Overview

Atlassian Cloud organisations often remove users from product‑access groups to save licence costs, but doing this without preparation can break assignments and mentions. The User Management and License Optimizer app automates the removal of product licences. The app provides a centralised dashboard to view, filter and manage users, groups and permissions and includes bulk operations and automated tasks .

This guide describes how to configure your organisation so that:

Users are deactivated from Jira/Confluence from a licensing perspective (no product seat 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 assign them back to a defined product role.

Prerequisites

Single sign‑on (SSO) set up and enforced – your organisation 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 organisation.
User Management and License Optimizer installed – this app will remove 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 licence.

1. Configure an authentication policy that enforces SSO

Sign in to admin.atlassian.com as an organisation admin.
Navigate to Security → User security → Authentication policies.
Click Add policy or edit an existing one and set Single sign‑on to ON and choose SSO only (no username/password login). Assign this policy to all users you plan to manage.

2. 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 http://example.com ).
Atlassian displays each product (Jira, Jira Service Management, Confluence, etc.). For each product, choose a Role (usually User) and uncheck Admin Approval as required if everyone from that domain should automatically get access. Leave the role as None for products you don’t want to assign.

Atlassian App Access per domain

When a user whose email matches the approved domain signs in via SSO for the first time (or after being deactivated), they’ll automatically be added back to the product’s licence group. This is how they regain their licence without manual intervention.

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 and License Optimizer app within your systems to manage final access assignments.

3. Deactivate users by removing product‑access groups only

The User Management and License Optimizer 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 licence.

4. Ensure unlicensed users stay assignable and mentionable

When a user loses their licence, 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

In each project where assignments should remain possible, go to Project (Space) settings → Access or People (for Team Managed Projects)
In each project where assignments should remain possible, go to Project (Space) settings → Permissions (for Company Managed projects)
1. Make sure that your group or user is included in the Assignable Users in your Permission schema.

Assignable User Permissions

Add the user (or a group that contains deactivated users) to a project role such as Developers or Service Desk Team. The role must have both Browse projects and Assignable user permissions.
Alternatively, create a dedicated group (e.g., inactive-users) and grant that group the necessary project permissions.

Project Access via deactivated user group

Confluence

The Atlassian workflow ensures Confluence Users are mentionable when added to a confluence_guest group. Deactivated users are labeled as guests, which also affects automatic reactivation. Users in this guest group can access Confluence but not the Spaces. To regain space access, users need to click the 'Request Space Access' button, triggering the automatic user provisioning workflow to restore product access. If mentioning users is unnecessary, it is recommended to skip this step with the guest group to facilitate a smoother auto-reactivation process.

Create a separate group for deactivated users and grant this group guest access to Confluence.
give guest Access to Confluence
For each space where you need to mention unlicensed users, go to Space Settings → Permissions.

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.

When you remove product access for Confluence using the user management and license optimizer app, it will also remove these deactivated user groups because they are assigned product access as a guest role. It's important to include an additional step in the remove product access automation: add to group and select the deactivated user group.

Keep this order for the Automated Task:

1. choose remove product access, select the products,

add to group, and select your deactivated user group.

The following behavior is successfully tested.

App	Assign	Mention	Notification
Jira	yes	yes	just for mentioning
Confluence	doesn’t exist	yes	no

5. Test reactivation via SSO

After a user has been deactivated, confirm that they no longer have the licence by viewing their profile in Atlassian Administration → Directory. They should not be a member of any product access group.

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 licence. They will now be able to log in normally.

6. 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 organisation 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.
License Optimizer automation: The app includes features to deactivate Product Access. The reactivation functions from Atlassian are not controlled via User Management and License Optimizer.

Conclusion

By combining Authentication policies, App access settings, and project/space permissions, you can deactivate inactive users to save license costs while preserving collaboration workflows. Deactivated users remain visible in user pickers and are automatically re-licensed when they return via SSO, ensuring a seamless process for both administrators and users.