Entra group not syncing with Jira space

Question

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 · Answer

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:

* 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.
* 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.
* 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) · Answer

@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 · Answer

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🤠