How Does Atlassian Handle Manually Invited Users Later Provisioned via IDP?

[Berk Atlasian]

I've manually invited a user via email (e.g., michael@company.com), but this user should have been IDP-synced (provisioned).

Now, the issue is that this user's groups are not syncing from the IDP even though the email address matches. When I list the user in the directory, it shows them as an invited user.

Does anyone know how the logic works in this scenario?

Specifically:

1. Does Atlassian merge users when they're first manually invited and later provisioned via the IDP?

2. Should I expect the user's groups to sync even though they were initially invited manually?

Any insights into handling this situation would be appreciated.

[Ed Letifov _TechTime - New Zealand_]

Hello, @Berk Atlasian 

1) Internally Atlassian maintains several cascading "directories" (you can think of these as "tables of user records") – the site users (that's where you can invite people), the org users (this could be managed and unmanaged), the managed accounts (that's accounts claimed by an org from the verified domain), the "synced" users. Depending on what version of the "user experience" you are on – in the UI you will see different "views" of some of these, e.g., old experience in admin.atlassian.com UI shows "managed users" separately from "all users", the new one shows them together...

Some of these directories can get out of sync – we have customers where groups are being pushed successfully but the count of "synced" users shows more than the number of group members reported both in Cloud and also on IdP side – these are leftover records, either from previous user provisioning integration attempts, or from users previously synced but then disappearing from the sync scope. Technically this is benign but it does throw one off at first...

The issue @Tomislav Tobijas _Koios_ referred to is also similar – the IdP information and Atlassian Cloud information about group membership or users is out of sync i.e. the IdP refuses to push the user to Atlassian Cloud as it seems "unnecesssary" from IdP's point of view.

2) When IdP is connected and syncs users, these user records are not "merged" but rather linked down this "cascade", and UI displays certain signs, e.g., lock icons on the user account – to signal this.

As already mentioned by @Tomislav Tobijas _Koios_ the link is by email address. Even though on the IdP side and in the User Provisioning configuration something else MUST be used as the matching attribute (e.g. objectId in EntraID), since everything else including UPN and email can change over user record lifecycle – once it crosses into Atlassian world, everything is the email. This is why it's so important to change your SSO configuration on the IdP side to use the email as the "username".

So for a previously invited users when they are now pushed from IdP, the IdP should "take over" by matching an email, and the lock icon should appear on the user. 

So does it for this user?

If it doesn't then before you resolve the groups sync – you need to resolve the user sync.

The should be signs in the troubleshooting logs, either or on both, Atlassian Cloud side and IdP side.

For example it may say on the Cloud side that "user with email xxx already exists" – what this really means is that the IdP, using something else as the identifier (=matching attribute) has latched onto a different record, and is trying to push your user's email there but can't since your user already exists with this email. So in this case the problem is not really your user but either a possible misconfiguration of the User Provisioning on the IdP side or a different record, possibly disabled by now that is interfering.

If you have a Solution Partner – ask them to investigate, they should be able to clear the link using "user provisioning REST API". If not, consider getting one or reach out to Atlassian, with specific user ID.

3) As a side note, in general, groups will only sync to the sites that belong to the same organisation that has the IdP pushing them.

[Tomislav Tobijas _Koios_]

Hi @Berk Atlasian ,

Let's say you have the following scenario:

1. You invited the user locally (e.g. user@company.com). Whether they've accepted the invite or not, the account should be created (they would just need to set up password).
2. Moving on, you've connected IdP.
   1. To do that means that you've verified domain(s). 
   2. After you've verified the domain (e.g. company.com) you need to claim accounts including the user account in step 1).
   3. Once you've claimed it, it should appear under Managed accounts.
3. Now, on the IdP side check if the user is inside groups that are being synced to Atlassian. If so, and when the sync is executed when you navigate to this specific managed account, it should be stated that the account is managed by your IdP.
   All group memberships of groups that are 'in sync' should be the same as on IdP side.

The 'UUID' when looking at the IdP and Atlassian Accounts is email. If the user already exists and you've claimed their account, IdP sync won't create a new Atlassian Account but rather just 'transfer management' from Atlassian Admin Hub to connected IdP.

---

As for group membership issues, I did have one problem with it recently. The issue was that the user was in groups on IdP side, and these groups also existed in Atlassian, but the same user wasn't in these groups on the Atlassian side. All other users were fine.
After some researching and reaching out to support team, the conclusion was that the user needs to be removed from IdP groups > wait for standard sync from IdP to Atlassian > re-added to groups on IdP side. After that, everything was fine.

But that was one case only. Usually, group memberships are synced properly (for groups that are defined in the sync configuration) and that's me talking specifically about Entra ID/ex. Azure AD. I am not sure how other IdP connections can be configured.

Cheers,
Tom