3. Setup Users Auto License Management

The Activate/Deactivate Users tab provides centralized control for managing your licensed users efficiently by automating key administrative tasks such as user activation, deactivation, and access revocation based on inactivity. This helps optimize license usage, enhance security, and ensure only relevant users retain access.

A. Summary Section

Auto License Management AUM

Upon navigating to the Activate/Deactivate Users tab, you will land on the Summary screen. This provides quick insights into:

  • License Management: display the status of reactivation and floating license toggle

  • Scheduler Status: View when the next scheduler run is planned.

  • Automation Overview: Displays which automation toggles are currently active.

You can click the Edit buttons to quickly access and configure license management rules or automation preferences.

Scheduler Configuration

Auto User Management AUM

The scheduler ensures your configured automations (e.g., user deactivation or group updates) are run automatically at a defined time.

Features:

  • Custom Time Setup: Define the exact time (HH:MM) at which the automation should run daily.(24 hr display time)

  • If the current time has already passed, the scheduler starts from the next scheduled day.

  • License Usage Alert: Enable the “License Usage Exceeded Alert Mail” toggle to receive emails when license consumption crosses a set threshold.

Example Use Case:

An admin sets the scheduler to run every day at 2:00 AM. This allows inactive users to be deactivated nightly without impacting working hours. If the license limit exceeds 500, the admin gets notified immediately to take corrective action.

B.Reactivate Tab

Reactive tab AUM

The Reactivate Users feature ensures seamless reactivation of inactive users when they attempt to log in—based on defined rules.

Key Toggles and Options:

  • Enable Reactivation: Automatically reactivates users upon login.

  • Add Groups After Login: Automatically assign specified groups to reactivated users.

  • Remove Groups After Login: Automatically remove unwanted groups from reactivated or active users on login.

Example Use Case:

A user who was marked inactive after 90 days returns for a new project. Upon login, their account is reactivated and assigned the group jira-developers, while outdated access like temp-access is removed automatically.

C.Deactivate Tab

This section allows for rule-based deactivation of users based on login activity.

Deactived tab AUM

Features:

  • Auto Deactivate Toggle: Set the number of days after which users with no activity are deactivated (default is 30).

  • Add Suffix to Username: Helps identify users who will be deactivated (e.g., appending “_deactivated” to usernames).

Preferences for Deactivation

Preferences for Deactivation AUM

  • Exclude Groups: Skip deactivation for certain critical groups (e.g., jira-admins, jira-software-user).

  • Select Directory: Choose specific directories for user evaluation.

  • Crowd Read-Only Support: Allow deactivation even for users from external read-only directories.

  • Include Never Logged-In Users: Deactivate users who have never logged in since account creation.

  • Include Once Logged-In Users: Deactivate users who logged in only once, with a day threshold.

Example Use Case:

You configure that users inactive for 45 days will be deactivated and receive the suffix "_old". Users in support-staff group are excluded from this rule. This lets your system remain lean without affecting ongoing support teams.

Ticket Handover Before Deactivation

Ticket Handover Before Deactivation AUM

This feature ensures tickets are not lost or orphaned during user deactivation.

Options:

  • Unassigned: All tickets will be unassigned before deactivation.

  • Assign to Project Lead: Tickets are reassigned to the lead of the corresponding project.

  • Assign to Specific User: You can select a user to whom all of the deactivated user’s tickets will be reassigned.

Example Use Case:

Before deactivating a QA engineer, the system reassigns their unresolved tickets to the test lead. This ensures no issue is left unattended post-deactivation.\

Email Notifications Before Deactivation

Email Notifications Before Deactivation

You can notify users ahead of their deactivation to reduce surprises or reactivation requests.

Configuration Options:

  • Set the number of days before deactivation that an email is sent.

  • Customize the subject and body of the notification email.

  • Separate toggle for users who have never logged in.

Example Use Case:

An email is sent 7 days before deactivation warning users that inactivity will lead to removal. A never-logged-in intern account created months ago receives a notice as well, with instructions to contact the admin if access is still needed.

D. Revoke Access Tab

The Revoke Access tab allows administrators to revoke application access for users who have been inactive over a certain period, while still keeping the user accounts in the system (i.e., not deleting or deactivating them). This approach helps enforce license hygiene and reduce unnecessary license usage without affecting user data or historical records.

Revoke Access Tab AUM

Key Features

Group-Based Access Revocation Toggle

Enables revoking access by removing users from specific groups after a defined period of inactivity.

  • Set Target Groups: Choose one or more groups from which users will be removed (e.g., jira-software-users or developers).

  • Set Inactive Days Threshold: Specify the number of days of inactivity after which the access should be revoked.

    • The default is 30 days.

Set Preferences

Set Preferences AUM

These preferences provide more granular control over which users should be evaluated for access revocation.

  • Exclude Groups from Revoking Access: Prevents revoking access for certain critical groups.

  • Select Directory for Revoking Access: Allows targeting specific internal or external directories for the revocation logic.

  • Include Never Logged-In Users: Revoke access for users who have never logged into the system.

  • Include Once Logged-In Users: Revoke access for users who have logged in only once and remained inactive beyond the defined days.

  • Crowd Read-Only Directory Support: If you're using external Crowd directories in read-only mode, this toggle allows user access revocation from those directories as well.

Example Use Case

Scenario: Your organization has a floating pool of users in a group jira-contractors. These users are expected to log in frequently for collaboration.

You configure the Revoke Access tab with:

  • Target group: jira-contractors

  • Inactivity threshold: 45 days

  • Include never-logged-in users: Enabled

Now, if a contractor hasn't logged in for 45 days or never logged in at all, their group access will be revoked, releasing the license and ensuring your user base remains compliant and clean.

E. Floating License Tab

The Floating License feature enables dynamic assignment of license-related groups to users at the time of login. This is done using rule-based logic to assign users to specific groups (e.g., jira-software-users, jira-servicedesk-users) only when required.

This is especially useful when your organization has more users than available licenses, and not all users require concurrent access.

Floating License Tab AUM

Key Features

Rule-Based Group Assignment Toggle

Enables rule-driven group assignments for license usage optimization.

  • Only applies to active users.

  • Deactivated users are not considered in this logic.

Define Mapping Rules

Each rule is defined as:

  • Source Groups ("If User Belongs to These Groups"): The initial group(s) a user belongs to (e.g., sales-team, external-contractors).

  • Target Groups ("Then Assign Them to These Groups"): The license or functional groups that should be added at login (e.g., jira-software-users).

Manage Rules

  • Add multiple rules based on different roles or departments.

  • Remove rules by clicking the ❌ icon beside the rule.

Example Use Case

Scenario: Your marketing team (marketing-users) and support team (support-temp) share a pool of Jira licenses. You have only 30 licenses but 60 users.

Configuration:

  • Rule 1: If user is in marketing-users, assign to jira-software-users

  • Rule 2: If user is in support-temp, assign to jira-servicedesk-users

When a user from either team logs in:

  • The system checks their base group.

  • Assigns them a license-based group only during active use.

This setup dynamically manages access and prevents license overconsumption.

F. Group Assignment Tab

The Group Assignment tab enables administrators to automatically assign specific groups to users who have been inactive for a defined number of days. This is especially useful for labeling, reporting, or grouping inactive users for specific workflows or audits without revoking their access.

Group Assignment Tab AUM

Key Features

Add Specific Groups to Inactive Users Toggle

Activates the logic for automatically tagging inactive users with a defined group.

  • Specify Target Groups: Enter one or more groups to assign (e.g., inactive-users, needs-review).

  • Set Inactivity Period: Define how many days of inactivity qualify a user for this assignment.

This does not affect login permissions but helps categorize and track inactive users more effectively.

How to View or Export Assigned Users

To audit or export these users:

  • Go to the Bulk User Management tab.

  • Use the Filter by Groups option.

  • Enter the target group(s) like inactive-users defined in this setting.

  • Apply the filter and export as CSV.

Example Use Case

Scenario: You want to track users who have not logged in for 60 days but do not want to deactivate or revoke their access yet.

You configure:

  • Inactivity threshold: 60 days

  • Assigned group: review-required

When the scheduler runs:

  • All users who meet the 60-day inactivity condition are added to the review-required group.

  • These users can now be reviewed periodically, reminded, or tracked for further action (like deactivation).