How Are You Managing License Optimisation and User Lifecycle Across Atlassian Cloud Instances?

[#1]

Hey Admins,

As our organizations grow and integrate more Atlassian Cloud products, keeping track of user lifecycle management and license optimisation is becoming a real balancing act especially when managing multiple instances or environments under an Enterprise agreement.

At Ignite, we’re currently focused on:

• Automating inactive user detection and license cleanup using ScriptRunner and native automation rules.

• Streamlining JSM agent provisioning/deprovisioning through Azure AD group mapping.

• Consolidating multiple Atlassian Cloud instances under a single Enterprise billing and identity structure.

It’s been an insightful process, equal parts governance, automation, and communication.

I’d love to hear from other admins:

• How are you handling license lifecycle and optimisation in your environment
• Are you using built-in tools (Access, Admin Hub reports), or relying on third-party apps for automation and insight?
• Any key lessons learned during cloud instance consolidation or Enterprise billing migration?

Let’s compare notes, what’s working well for you, and what would you love Atlassian to improve in this area?

Cheers,
Suraj Aderogba

[Waheed Olanipekun]

Very nice Suraj.

Thank you for sharing.

[Tobias Bosshard]

Dear Suraj.
in our use case, the "master" of the user management is Entra/AD. We don't have Jira Guard, because it's too expensive for us.
Often, I don't receive any notification when an user left the company (worldwide locale user admins).
My solution is now, that I check monthly with an automation if a Jira user is still active in Entra.
I have manually to copy all email addresses from the Jira  (active Jira users => export) to the automation for "Create lookup table".
Then the automation checks for each user "Check if user is enabled in Entra ID". So I receive a list with all inactive users in Entra.
BR Toby

[Josh McManus]

I'm working on a plan for this currently with my organization.

We have Atlassian Guard, and we use Okta as our SSO solution (with AD underpinning it). My plan so far has been to work with HR to come up with a list of consistent Roles within our organization that we can outline for every new Job Requisition we post, and then work with IT to assign our current employee base to those roles. From here I plan on associating roles with synchronized groups with specifically assigned App access. Additionally I will synchronize Atlassian Groups with the Okta groups and build a role-based permission structure off of that. Ideally this should reduce the administrative overhead for application and project access.

Because we also operate with external development partners, our current model relies upon us creating email addresses for these external users and then it takes up a seat of access for these external users...but the additional downside is that we don't have a great way to audit that list and we don't have the support communications set up to be able to monitor when these external parties may have departed their company. My plan for this is to use External Share for Jira to provide domain access to isolated boards for these external organizations and leverage MFA to ensure only active and current employees from these orgs have access. For issue creation we will use Public Forms and through the combination of these two features we should be able to provide access without using up license seats. I'll be sure to update how that goes once we finish setting it up!

[Surajudeen Aderogba]

Hi @Tobias Bosshard That’s a smart workaround using Entra ID as your source of truth and automating the inactive user check makes perfect sense, especially without Jira Guard.

If you want to take it a step further, you could skip the manual export by pulling Jira users directly via the REST API (/rest/api/3/users/search) and comparing them to Entra ID data from the Microsoft Graph API. That way, your automation stays up to date and runs on its own.

If you share what tool you’re using, I can suggest a quick way to wire that up.

Best,
Suraj

[Surajudeen Aderogba]

Hey @Josh McManus That sounds like a really smart setup. Tying access control to HR-defined roles and syncing Okta groups with Atlassian ones is exactly the kind of structure that saves a lot of admin headaches later on.

I like your plan for external users too, using External Share and Public Forms keeps things clean without burning extra licenses, and adding MFA is a nice touch for security.

Would definitely love to hear how it all works once you’ve rolled it out, especially how smooth the Okta–Atlassian sync is in practice with Guard involved. A lot of teams could learn from that approach.

Suraj

[Rune Rasmussen]

We provision all users through Atlassian Guard.
There is a dynamic group with all employees that gives JSM Customer access.
Then separate groups for licenses. One pr. product.
Other groups also exist for in-product accesses or permissions, like to certain Projects/Spaces or product admin permissions.

On the Azure end of things, when an employee leaves a script runs and removes them from any of our Atlassian Cloud related groups.

On top of that we do an export of all users every six months and import that into a pre-made spreadsheet.
Any user whos "last seen" date is more than 3 months ago just gets their respective license revoked.

The "last seen" timestamp seems a bit unreliable for Jira Service Management, but with our limited time and resources it'll have to do for now.