Skip to content

Atlassian Access – Streamline your billable users

If you’re reading this, you probably use Atlassian Access at your organisation. You’ve probably also discovered that you have users in your claimed domain that have at some point in their lives, signed up for free Trello, Bitbucket, or other Atlassian Cloud products. This means that you now have to pay for them as billable users which is costing you more money. 

NOTE: If you’re an Enterprise customer, you won’t be impacted because you’ll get unlimited Atlassian Access users anyway.
NOTE: As it’s the most common problem, I’ll continue the article referring to Trello.

An example scenario of this is below:

ScenarioBillable User CountComments
10,000 Users: Claimed domain accounts0Using Atlassian Access means the domain must be claimed and all email addresses associated can be claimed.
200 Agents: Jira Service Management200
$8,000 p/a		Each user with ‘Product Access’ counts as a billable user.
9,800 Unlicensed: Portal Customers200
$8,000 p/a		These users aren’t considered billable users so don’t add to the billable user count
They can use the JSM portal as a portal customer.
300 Portal Customers:Signed up for Trello Free500
$17,500 p/a		These users haven’t intentionally been given access to a licensed product.
However, because they signed up to Trello Free, this is considered to be ‘Product Access’ to Trello and they are considered billable users.
As you can see this can cause a significant increase to the licensing cost of Atlassian Access.
Table 1: Billable User Count Scenario

NOTE: If your claimed domain users are given product access (even on a free / trial site) on a third-party cloud site that you don’t manage, they will also be counted as a billable user.

NOTE: Users you’ve already intentionally licensed for a product aren’t affected by this. For example a user that has already been given a Jira Software licence is still ONE billable user but could have product access / licences on any cloud site for JSM, Confluence, Trello and Bitbucket.

How can we address this?

I’ve worked with many organisations that have found themselves paying for more users than expected. It’s alarmingly common for users to sign up to free web services with their company email address for trials to check out functionality for a business use case. In the case of Trello, they have then become billable users whether they continue to use the product or not.

As security is such a high priority for organisations and Atlassian Access is required for enforced MFA, this often just gets accepted and paid for.

There are a few options to streamline what users are included in your billable user count. Different options will suit different organisations depending on their setup,what products they have, whether an identity provider is set up and their individual priorities.

Option 1 – Don’t claim the impacted accounts

If you haven’t yet claimed the accounts associated with your domain, there is a step during the claim process that allows you to download a CSV file of all accounts associated with your domain and this includes what associated product access they have.

Upon reviewing this if you see that you have a high volume of Trello users with no other licenced product access, you can decide to upload a CSV of accounts that you do want to claim, which can exclude the Trello users.

The problem with this is that for your excluded users, you lose the functionality to:

  • Enforce single sign-on
  • Require MFA
  • Sync these accounts with your identity provider for group / licence management

For most organisations, the lost functionality above are the reasons that they purchased Atlassian Access in the first place. Removing the enhanced security controls for a subset of users increases the security risk for those accounts.

If you don’t have Jira Service Management, these users won’t need to sign into your Customer Portal so leaving them out of your managed Atlassian products may be acceptable to you.

Option 2 – Create a non-billable policy

If you have claimed the accounts, a quick simple way to remove them from the billable count is to move impacted users to a non-billable policy. The steps to do this are in the Atlassian support documentation here:

What is a non-billable policy?

Again, for the users in the non-billable policy they will lose the functionality mentioned above in option 1. This may also be acceptable if users don’t need to access the JSM Customer Portal.

Option 3 – Delete the Trello Workspace

If the user is still active at your organisation, you can contact them and find out if Trello is still in use / required. If not the user can delete their own workspace using the steps below:

Deleting a workspace

If the user has left the organisation then you will be able to delete / deactivate the user as described in option 4 below, or the IDP should have disabled the account when their work account was disabled.

If you have multiple users that are part of a workspace that they don’t administer, this can be tricky. Atlassian have provided options below however it assumes that you can get access to the email of an old admin in order to log in as them and delete the workspaces.

How to work with admins of discovered products?

Option 4 – Delete / deactivate the user (No IDP management)

If your claimed domain accounts aren’t managed by an identity provider, you’ll be able to delete or deactivate the impacted accounts from your site. This action only really makes sense for users that have left your organisation as they will no longer be able to access any other products.

NOTE: If user provisioning is not set up and syncing with your IDP, users that have had their work account deactivated / deleted will still have a working and (potentially billable) Atlassian Account that will need to be manually deactivated.

Option 5 – Get Atlassian support

For users that are synced and managed by your IDP, you will not have access to edit / delete these user accounts. You can submit a list of Trello accounts that are no longer required to Atlassian and request that they are permanently deleted.

NOTE: If the impacted user was the only one with access to a Trello board, that board will also be deleted.

On the next sync with your identity provider, they will get new accounts created that don’t have Trello associated with them and they’ll be considered ‘Portal Customers’ with no association to Trello and will not be considered billable users.

When this happens however, the new accounts that have been created will have no relationship with their previous tickets that they created. If the deleted + recreated user had 300 requests raised on their deleted account, their new account will have no access to them without some manual intervention.

Note: This can have an impact on governance, approvals, reporting and audit as the newly created account belonging to the same user, won’t have any relation to any approvals, actions, comments made by the old account.

If this isn’t important to your users / org, this might be the easiest option.

Option 6 – The DIY option

For users that are synced and managed by your IDP, you will not have access to edit / delete these user accounts. If the user count impacted by Trello accounts is relatively low, you may wish to manually disable the Trello accounts using the REST API and sync new accounts from the identity provider. The below API requests can be scripted in a supported language or processed through a tool like Postman.

Note: This requires access to ‘Org admin’ roles and the identity provider admin.

  • Find your user provisioning API key
    • Documentation here
    • As an Org Admin you should have your user provisioning API key stored somewhere safe already
    • If for whatever reason this wasn’t documented or handed over, you can regenerate your API key
      • IMPORTANT: This would then need to be updated with your IDP
  • * Pause the user provisioning in your identity provider
  • Find the ID of the impacted user(s) using the email address
    • Request Type: GET
    • URL: https://api.atlassian.com/scim/directory/{directoryId}/Users
    • Params: filter=userName eq “<email address>”
    • The full HTTP request will look like the example below:
      • https://api.atlassian.com/scim/directory/{directoryid}/Users?filter=userName eq “some.person@YourClaimedDomain.com”
    • Headers: ‘Authorization: Bearer <api-key>’,  ‘Accept: application/json’
    • This will return the “id” value
  • Delete the entry from the SCIM directory
  • Change the email address of the impacted users
  • * Turn user provisioning back on in your identity provider
  • * Manually re-sync the impacted users
    • This creates new accounts for the synced users
  • Bulk update associated tickets from the old to new account
  • Get users impacted users to log in
    • This re-syncs the email address with the correct entry in the SCIM directory
  • Disable the OLD accounts

*These processes are different depending on which identity provider you’re using. Please refer to your identity provider documentation if needed.

Improvements Coming

There is a passionate community feeding into Atlassian to address these kinds of issues. If this impacts you, please start by voting and following here:

Allow Administrators to control managed users’ associated sites and products

Deny new product sign ups

In Q4 2023, Atlassian are planning to release the first iteration of features allowing admins to deny new product instances being created through a lightweight ticketing system.

Track the roadmap item here: Product Requests

This can at least prevent your users from signing up to new products using their claimed domain accounts and increasing the billable user count.

Summary

I hope the above options have been useful. For assistance in getting the most out of your Atlassian products, do not hesitate to contact us or have a look at our dedicated Atlassian Partner Page.

Join us at the next Atlassian Community Event on the 7th of June to find out more:

https://ace.atlassian.com/events/details/atlassian-bristol-presents-bristol-atlassian-community-event-1/

About Devoteam A Cloud

With 500 clients across Europe, Devoteam A Cloud offers excellent know-how on AWS technologies since 2012. Our team of 550+ AWS experts supports customers with scalable infrastructure, new ways of thinking and operating enabled by AWS so that they can explore new possibilities, re-invent their business, and evolve into an enterprise platform. 

Devoteam is an Atlassian Platinum Solution Partner, we have passed the strictest training requirements and have a tried-and-true business model that can scale from serving small to very large clients. We are well equipped to manage a variety of customer solutions and have an established run rate of Atlassian business. With a team of Global Certified Individuals, we try to improve our and your business as much as possible. We try to provide amazing products and services tailored for your team.

David Meredith
Senior IT Service Management Consultant
Devoteam UK