Entra group not syncing with Jira space

[Mike Perera]

Hi,  We created an Entra group for user testing, and all members of the group have successfully synced to the corresponding Jira space except for three staff members.

We removed these users from the Entra group and added them back again to trigger the sync, but they still have not been synced to Jira.

Can this be synced manually as the auto sync for three staff members are not working?

[Sami Shaik]

Hello @Mike Perera , your direct question first, because it has been left hanging: can Atlassian manually sync it? Not in the direction you mean, but there is one case where Support is exactly the right call, and the three-minute check below tells you which case you are in.

Why "Atlassian can force a sync" is half wrong. SCIM is a push from Entra to Atlassian; Atlassian holds what Entra sent and cannot ask for more. @Abaho Katabarwa _Katabarwa Labs_  is right that the sync itself is Entra's. What Atlassian's side can do is repair drift between its own SCIM directory and the site groups, which is a documented failure mode: the User provisioning page shows the right member count for the group, the Troubleshooting log is clean, and the site's group page still lacks the members (ACCESS-1380). That is the case @Jovânio Junior is describing, and it is a Support ticket, not something you can fix from the console.

The three-minute check that separates the two cases:

1. Atlassian Administration, Security, Identity providers, your directory, then User provisioning and the Troubleshooting log (Understand user provisioning). Search for each of the three users. If they appear with an error (out of scope, attribute conflict, identifier mismatch), the cause is on the Entra side and the log line names it.
2. On the same page, compare the group's member count with Entra's. If Atlassian's count matches Entra's but the site group is short, that is the ACCESS-1380 shape; open a Support ticket with the group name and the three accounts, and they can re-sync the directory to the site.
3. If Atlassian's count is also short, the three users never arrived. Two causes cover almost every case: they are members through a nested group (the SCIM connector does not flatten nesting; only the separate Entra-for-nested-groups connection does, per this doc), or their identifier does not match what the directory was set up to use (UPN versus email; a user whose UPN and mail differ will match on one and not the other). @Arkadiusz Wroblewski  and @Abaho Katabarwa _Katabarwa Labs_  both named these, and they are the right two.

Forcing it from the Entra side, which is where the lever actually lives: in the Atlassian enterprise application in Entra, Provision on demand for one of the three users pushes them immediately and shows you the exact SCIM request and response, including any rejection reason; that is faster and more informative than remove-and-re-add, which only re-queues them into the next incremental cycle. If all three succeed on demand, the incremental cycle was the problem, and a Restart provisioning clears its state.

Report back which of the three cases it was, the log line or the on-demand response will say.

[Abaho Katabarwa _Katabarwa Labs_]

@Mike Perera 

On your last question: there is no manual sync you can trigger from the Atlassian side, and support generally cannot force one either. The sync is driven by your identity provider pushing through SCIM, so the fix happens in the provisioning logs the folks above pointed to. For three stuck users out of a full group, the usual culprits are an email or UPN mismatch with an existing Atlassian account, or membership through a nested group, since Atlassian SCIM only syncs direct members. A practical stopgap while you debug: SCIM-synced groups are read-only in Atlassian admin, so create a separate local (non-synced) group, add the three users to it, and give that group the same product access and project role. They get working access today and the IdP cannot overwrite it.

Full disclosure, I work for Katabarwa Labs and we build a governance app for Jira called Access Governance Reporter. It will not fix the sync itself, that problem lives upstream in SCIM. What it does give you is the downstream evidence: per user, every project and permission they actually hold and the exact group or role granting it, so you can verify whether those three really lack the access the group should carry, and prove when it lands. Runs entirely on Atlassian Forge in your own tenant, no data egress.

Marketplace: Access Governance Reporter

If a view that reconciles group membership against actual project access, exactly for catching SCIM gaps like this, would help you, tell us and we will build it.

[Arkadiusz Wroblewski]

Hello @Mike Perera 

An Entra group doesn’t sync directly to a Jira space. The overall path goes like this:

1. Entra

2. Atlassian group membership

3. Product access

4. Jira space role/permissions

To troubleshoot, first check Atlassian Administration → Directory → Groups and look for your synced Entra group. Make sure those three users are listed as members. 

It's also important to confirm that they are direct members of the Entra group. Sometimes, memberships from nested groups don’t sync correctly in Atlassian, so if those three only belong through a nested group, that could explain the issue.

Best,

Arek🤠

[Jovânio Junior]

Hi Mike,

Yes — before removing and re-adding the users again, I’d check the provisioning logs because if only 3 users are failing while the rest of the Entra group synced successfully, this is more likely to be a user-specific provisioning issue than a problem with the group itself.

In Atlassian Administration, go to the Identity Provider / User Provisioning configuration and check the Troubleshooting log. Atlassian specifically recommends this when users or group memberships don’t sync as expected.

A few things I would validate for those three users:

whether their email/UPN matches the attribute configured for provisioning;
whether their Atlassian accounts already exist under another email address;
whether their domain is verified/linked to the correct identity provider;
whether Entra shows any provisioning error for those individual users;
whether the group membership itself is being successfully pushed through SCIM.

If you are using Atlassian’s newer directory sync option, there is a Sync now option in Atlassian Administration that can manually trigger a synchronization when no sync is currently running.

If you are using standard Microsoft Entra SCIM provisioning, you can also use Provision on demand from Entra to force provisioning for an individual user. Atlassian documents this as a way to manually trigger provisioning for one or more users and observe the result.

So for only three affected users, I would probably try:

Entra → Enterprise Application → Atlassian Cloud → Provisioning → Provision on demand

and test one of the affected accounts first.

That should also give you a much clearer error message if something specific about the user account is preventing the sync.

Hope this helps!

[Mike Perera]

Hi @Jovânio Junior 

Can we request from Atlassian to manually sync this as we are unable to do it form our end? Thanks

[Jovânio Junior]

Yes, with support Atlassian thas is possible