How does your organization handle Atlassian user provisioning and license management?
If you run SCIM provisioning with Atlassian Guard, you've probably asked yourself this question at some point:
"Our IdP already manages user accounts and groups automatically โ can we still use a license management app alongside it?"
Automated provisioning through an IdP (Identity Provider) dramatically simplifies onboarding and offboarding.
From a licensing perspective, however, one challenge remains.
Creating accounts and g licenses efficiently are two different problems.
Licenses being consumed automatically just by provisioning, or long-inactive accounts holding on to licenses โ these are problems an IdP alone can't solve.
Here's the short answer:
Using Atlassian Guard (IdP) and Flexible User License together solves this problem.
The two tools don't replace each other.
They form aย complementary structure, each owning a different domain: identity management and license optimization.
ย
Atlassian License Management by Role Separation
Who Handles What?
Let's start by clearly defining what each system is responsible for.
IdP (Atlassian Guard ยท SCIM) โ Account creation, organization membership, SSO authentication, deactivating leavers (identity management)
Atlassian โ Granting and managing product access (licenses)
Flexible User License โ Optimizing licenses based on user activity
In other words:
The IdP manages "who belongs to the organization"
Atlassian defines "who can use the products"
Flexible User License ensures "only people who actually use the products consume licenses"
With the roles divided this way, you get one consistent license operating model.
ย
Why Does Role Separation Matter?
Without role separation, multiple systems end up managing the same group at the same time.
In that setup:
The result is a structure where optimization never sticks.
ย
Before and After Role Separation
Simply dividing the roles reduces operational complexity and significantly improves license efficiency.
One Owner for Your Product Access Groups
In Atlassian Cloud, product access (licenses) is determined by membership in groups that have been granted product access.
So what happens if the IdP syncs those groups?
The IdP treats itself as the source of truth and re-asserts group membership on every sync.
That's normal IdP behavior โ it exists to keep identity data accurate.
In this configuration, however, any membership that Flexible User License has optimized based on activity gets realigned to the IdP's state on the next sync, so the optimization doesn't hold. Fortunately, the fix is simple.
Give each product access group exactly one owner.
Create the groups that grant product access as local groups within the Atlassian directory, and let Flexible User License manage them based on activity.
The IdP focuses on identity management and leaves these groups out of its sync scope.
Atlassian recommends the same approach. Groups synced via SCIM from an external IdP are read-only and can't be set as default groups. To manage product access effectively, Atlassian advises creating internally managed groups in Atlassian Cloud. Atlassian also notes that automatic assignment to default groups can lead to unintended license consumption if not configured properly.
Configuration: 4 Steps in Atlassian Cloud
Now let's walk through the actual setup. We'll use Microsoft Entra ID as the IdP in this example, but the same principles apply to any IdP that supports SCIM.
1. Scope SCIM Provisioning to "Account Creation + Org Membership"
Provision users from your IdP, but don't map them to any group that grants product access.
Users created by the IdP join Atlassian as "organization members without a license." New-hire onboarding stays fully automated through the IdP, while license assignment becomes a separate step.
2. Remove Product Access from Synced Groups + Review Default Groups
If any SCIM-synced group has product access attached, remove it.
Also review your default group settings. Users provisioned from an IdP aren't added to default groups automatically โ but users who are invited manually or who sign up through an approved domain are auto-assigned to default groups and consume licenses. Make sure no group with product access is set as a default group. Sort out these two settings, and unintended license consumption disappears regardless of how an account was created.
3. Keep Product Access Groups as Local Groups
Create a local group in the Atlassian directory to grant product access, and attach product access to that group.
Since this group isn't synced from the IdP, Flexible User License can manage its membership reliably with activity-based rules โ reclaiming licenses from inactive users, maintaining license caps, and more. With a clear single owner, the optimization results stay intact.
4. Offboard Through the IdP, Just Like Today
The leaver process doesn't change. Deactivate the account in your IdP, and the Atlassian account is deactivated along with it โ automatically releasing the license that user was holding.
The License Flow After Configuration
Every step has a clear owner, and licenses always stay aligned with actual users.
Wrapping Up
Atlassian Guard (IdP) and Flexible User License aren't tools that replace each other โ they're a structure that creates more value when used together.
Divide the roles so that:
The IdP owns identity management
Atlassian owns access control
Flexible User License owns cost optimization
You keep all the convenience of automation, while building a structure where licenses are used only as much as actually needed.
Start dividing the roles between Atlassian Guard and Flexible User License, and run your license management more simply and efficiently.
ย
ย
๐ Try Flexible User License for Jira for free
๐ Try Flexible User License for Confluence for free
How does your organization handle Atlassian user provisioning and license management?
If you run SCIM provisioning with Atlassian Guard, you've probably asked yourself this question at some point:
"Our IdP already manages user accounts and groups automatically โ can we still use a license management app alongside it?"
Automated provisioning through an IdP (Identity Provider) dramatically simplifies onboarding and offboarding.
From a licensing perspective, however, one challenge remains.
Creating accounts and g licenses efficiently are two different problems.
Licenses being consumed automatically just by provisioning, or long-inactive accounts holding on to licenses โ these are problems an IdP alone can't solve.
Here's the short answer:
Using Atlassian Guard (IdP) and Flexible User License together solves this problem.
The two tools don't replace each other.
They form aย complementary structure, each owning a different domain: identity management and license optimization.
ย
Atlassian License Management by Role Separation
Who Handles What?
Let's start by clearly defining what each system is responsible for.
IdP (Atlassian Guard ยท SCIM) โ Account creation, organization membership, SSO authentication, deactivating leavers (identity management)
Atlassian โ Granting and managing product access (licenses)
Flexible User License โ Optimizing licenses based on user activity
In other words:
The IdP manages "who belongs to the organization"
Atlassian defines "who can use the products"
Flexible User License ensures "only people who actually use the products consume licenses"
With the roles divided this way, you get one consistent license operating model.
ย
Why Does Role Separation Matter?
Without role separation, multiple systems end up managing the same group at the same time.
In that setup:
The IdP keeps enforcing membership based on its sync state
Flexible User License keeps adjusting membership based on activity
The result is a structure where optimization never sticks.
ย
Before and After Role Separation
Simply dividing the roles reduces operational complexity and significantly improves license efficiency.
One Owner for Your Product Access Groups
In Atlassian Cloud, product access (licenses) is determined by membership in groups that have been granted product access.
So what happens if the IdP syncs those groups?
The IdP treats itself as the source of truth and re-asserts group membership on every sync.
That's normal IdP behavior โ it exists to keep identity data accurate.
In this configuration, however, any membership that Flexible User License has optimized based on activity gets realigned to the IdP's state on the next sync, so the optimization doesn't hold. Fortunately, the fix is simple.
Give each product access group exactly one owner.
Create the groups that grant product access as local groups within the Atlassian directory, and let Flexible User License manage them based on activity.
The IdP focuses on identity management and leaves these groups out of its sync scope.
Atlassian recommends the same approach. Groups synced via SCIM from an external IdP are read-only and can't be set as default groups. To manage product access effectively, Atlassian advises creating internally managed groups in Atlassian Cloud. Atlassian also notes that automatic assignment to default groups can lead to unintended license consumption if not configured properly.
Configuration: 4 Steps in Atlassian Cloud
Now let's walk through the actual setup. We'll use Microsoft Entra ID as the IdP in this example, but the same principles apply to any IdP that supports SCIM.
1. Scope SCIM Provisioning to "Account Creation + Org Membership"
Provision users from your IdP, but don't map them to any group that grants product access.
Users created by the IdP join Atlassian as "organization members without a license." New-hire onboarding stays fully automated through the IdP, while license assignment becomes a separate step.
2. Remove Product Access from Synced Groups + Review Default Groups
If any SCIM-synced group has product access attached, remove it.
Also review your default group settings. Users provisioned from an IdP aren't added to default groups automatically โ but users who are invited manually or who sign up through an approved domain are auto-assigned to default groups and consume licenses. Make sure no group with product access is set as a default group. Sort out these two settings, and unintended license consumption disappears regardless of how an account was created.
3. Keep Product Access Groups as Local Groups
Create a local group in the Atlassian directory to grant product access, and attach product access to that group.
Since this group isn't synced from the IdP, Flexible User License can manage its membership reliably with activity-based rules โ reclaiming licenses from inactive users, maintaining license caps, and more. With a clear single owner, the optimization results stay intact.
4. Offboard Through the IdP, Just Like Today
The leaver process doesn't change. Deactivate the account in your IdP, and the Atlassian account is deactivated along with it โ automatically releasing the license that user was holding.
The License Flow After Configuration
Every step has a clear owner, and licenses always stay aligned with actual users.
Wrapping Up
Atlassian Guard (IdP) and Flexible User License aren't tools that replace each other โ they're a structure that creates more value when used together.
Divide the roles so that:
The IdP owns identity management
Atlassian owns access control
Flexible User License owns cost optimization
You keep all the convenience of automation, while building a structure where licenses are used only as much as actually needed.
Start dividing the roles between Atlassian Guard and Flexible User License, and run your license management more simply and efficiently.
ย
ย
๐ Try Flexible User License for Jira for free
๐ Try Flexible User License for Confluence for free