Users in Jira Groups But Not in Okta Push Groups

[Thomas Barnes]

We have found some discrepancies where a few users are part of Jira Target groups and are not part of Okta push groups.

Since Okta is the source of truth for these target groups, we want to understand what happened.

Users are part of the Target Jira Group and not Is not part of the target okta push group

What should be the next step to get these users removed from the Jira group once the Jira groups are Okta governed

What has caused the issue, this is important to know as these users were consuming Jira licenses and we can't have this happening in the future.

there are no errors or indication of any problems with the okta push groups

thanks

[James Gamble]

Hola Thomas,

Since Okta is intended to be the source of truth for those groups, I wouldn’t remove users manually from Jira first. Atlassian treats SCIM-synced groups as externally managed, and membership changes are supposed to come from the identity provider. 

The first thing I’d check is whether the affected Jira group is actually the SCIM-synced group you think it is, rather than an internally managed Atlassian group with the same or a very similar name. In Atlassian Administration > Directory > Groups, open the group and confirm that it shows as synced from the Okta identity provider. If it’s internally managed, Okta won’t govern its membership even if the names line up.

If it is definitely SCIM-managed, the discrepancy points to a stale or broken provisioning link rather than a normal group membership state. Atlassian explicitly states that SCIM links can become outdated after transient provisioning failures, leaving attributes or group memberships out of sync. Their current guidance for inspecting and repairing those sync relationships is here.

On the Okta side, I’d inspect the Atlassian application’s System Log for one affected user and group, looking specifically for the Group Push membership removal event rather than only checking whether the group itself reports as healthy. A group can remain successfully pushed even if an individual membership update has failed or has never been sent.

I’d also verify that those users aren’t receiving Jira access through another group. Atlassian licensing is based on product access, so removing someone from the expected Okta-pushed group won’t free the license if another SCIM group, internal group, or access rule still grants Jira. Atlassian Administration > Directory > Users > affected user > Groups and product access is the place I’d compare against Okta.

If Okta shows the users removed, Atlassian shows the same group as SCIM-managed, and no membership-removal event explains the difference, I’d open a case with Atlassian Support rather than manually correcting the group. Include the Okta group ID, Atlassian group ID, affected account IDs, timestamps, and Okta System Log entries to help them determine whether the SCIM membership link is stale.

Thanks,

James