nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Suraj Aderogba_sfd2f4

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.

As a solution architect and Atlassian solution expert, i’ve been focusing 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

Comments

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!

Suraj Aderogba_sfd2f4

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

Suraj Aderogba_sfd2f4

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.

Suraj Aderogba_sfd2f4

@Rune Rasmussen

Thanks for sharing your setup, this is a really clean and efficient approach. I like how you’re combining Atlassian Guard automation with Azure cleanup and a manual biannual review for inactive users.

You’re right about the “last seen” timestamp being a bit inconsistent for JSM users, especially when customers interact via email instead of the portal. I’ve seen similar gaps. Still, your layered process seems like a solid balance between automation and oversight.

Great insight, appreciate you sharing this!

Former user

Wow!

Initially, loved the Suraj's question, it's a great one! Then, I was checking the others guy's comments they have great ideas and solutions for this,. Definitely, I will following this up and test some in mine.

Andrew Fernando_pywja8

Curious about this. @Rune Rasmussen or any other group with EntraID/Azure, anyone using Dynamic groups from EntraID? I read on another thread that when someone is removed from the dynamic group, they are NOT seeing them being removed on Jira group.

Rune Rasmussen

@Andrew Fernando What we've run into historically is provisioned users not being removed from groups when they were deactivated in Entra.
The Atlassian Account would still become deactivated, but any group memberships in Atlassian Cloud would remain. For the most part no actual problems would manifest from that, but we did run into a few occasions of an employee leaving, coming back, and then unintentionally having their previous accesses and permissions still in place.

This should be fixed now though.
Confirmed by Atlassian on ACCESS-2449.

But group membership for active users has always worked as it should for us, no matter the assignment type.

Another sort-of-adjacent thing we've run into was the "User removed from group" Confluence automation trigger not actually triggering.
That was fixed shortly after us submitting a support ticket about it.

Tanishka Tandon

@Rune Rasmussen I completely agree with the headache and manual effort involved in handling deactivated accounts, especially when they have to be managed across multiple applications. Even if an account is left active in just one place, it may still be consuming licenses and increasing costs.

This becomes even more concerning when an employee leaves the company, but their access and permissions are still active. Managing all of this manually can quickly become chaotic.

But what if all of this could be managed automatically—not just across the Atlassian suite, but also across providers like Entra and Okta, etc, directly from the native JSM portal?

With just one request, employee lifecycle actions such as onboarding, provisioning, offboarding, and deprovisioning can be managed without going through each application separately.

Our Automate Access request & Review For AWS, Entra & Okta helps make this possible. And for every action taken, an audit trail is available so you can always track it afterwards.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

jira-administration

licence

administration

atlassian-cloud