A "floating license" is a process that ensures users do not consume license seats when they are not actively logged into the application. This allows organisations to significantly reduce their licensing costs, as they only pay for the user seats that are actually being used.

User Management supports removing user licenses (via removing groups) after short periods of time, and re-adding them to those groups when they next login (assuming the User Directories are configured to allow updating groups). This allows administrators to implement a floating license process.

However, there are a few things to be aware of with any floating license implementation with respect to Atlassian products.


Things to be aware of:

User Management can deactivate users based on "time since last login". We recommend this is always at least as long as the session timeout. If this time is shorter than the session timeout for your application, users may have access and permissions removed while they are still actively using the application. For more information on configuring the Session timeout, take a look at the relevant Atlassian documentation: 

Useful functionality is removed when application access is removed for users who may still be regular users. For example:

Jira:

  • Jira version 8.19.x does not allow sending issue notification emails to users without a current license.
  • Jira versions after 8.20.6 require setting a "Dark Feature" flag to send issue notification emails to users without a current license - see https://jira.atlassian.com/browse/JRASERVER-73165.
  • Issue filter subscriptions are not sent to users without a current license.

Confluence:

  • Cannot @mention users without a current license.
  • Notifications about changes to watched pages and spaces will not be sent to users without a current license.
  • Notifications about comments and inline comments will not be sent to users who do not have a current license.

Bitbucket:

  • Users without a license can be mentioned, added to PR's and receive notifications; however, ensure any application access groups are not used in the repository permissions if they are being removed regularly.

Atlassian's license model is not based on concurrent users, so implementing a floating license process may not fit within the Atlassian License:

A user is, by definition, an account with the permission to log into the application. A named user with this permission is counted towards the user limit, whether logged in to the application or not. Only one individual, a named person, is permitted per product login. Multiple people cannot share a product login. Our licensing model is not based on concurrent users.

https://www.atlassian.com/licensing/purchase-licensing#licensing

See also section 3.2 (e) of the Atlassian Software Agreement: https://www.atlassian.com/legal/software-license-agreement

Except as otherwise expressly permitted in this Agreement, you will not: (a) reproduce, modify, adapt or create derivative works of any part of the Software; (b) rent, lease, distribute, sell, sublicense, transfer, or provide access to the Software to a third party; (c) use the Software for the benefit of any third party; (d) incorporate the Software into a product or service you provide to a third party; (e) interfere with any license key mechanism in the Software or otherwise circumvent mechanisms in the Software intended to limit your use; 

Do you really need a floating license implementation?

Many of our customers find they can significantly reduce their license level simply by removing application access of users who are really no longer using Jira, Confluence or Bitbucket.

You can investigate how implementing a scheduled deactivation of users who have been inactive for 30 or 90 days will impact your license level using our User Insights feature:

More information

Please about User Management benefits and review Scheduled User Actions and Bulk User Actions user cases.




User Management Articles

Try for free

User Management for Jira, Confluence and Bitbucket

Try for free