Summary

Attempts to update a user sync record via provisioning sync results in a 409 response. The error message in Entra ID reads "Failed to update User 'username@domain' in AtlassianCloud" appears when attempting to provision a user account on-demand from the Atlassian Cloud Enterprise Application in Azure. Another potential issue is one where a new Atlassian account email address was created for the end user instead of the existing Atlassian account email address being updated via provisioning sync.

Notes

This document covers Entra ID specifically, but the logic and error message applies to any identity provider(IdP).

Replicating the issue

Following the steps below (provision on demand):

1. In Entra ID, click on Enterprise applications
2. Locate and select the Atlassian Cloud(default name) application
3. Click on Provisioning under the Manage section
4. Click on Provision on demand
5. Search for and select a user 
6. Click on Provision

Result is a 409 response:

{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"status":"409","scimType":"uniqueness","detail":"Resource [USER]: with email[email@domain] already exists."}

Resolution

Scenario 1: An Atlassian account with the target email address already exists (409 status code)

Scenario 2: The provisioning sync create a new Atlassian account instead of updating 

Scenario 1

Resolve any duplicate Atlassian accounts if any exist

1. Navigate to your Atlassian organization
2. Go to Directory > Managed accounts and search for the target email address
3. Atlassian account holding the target email address should be found. The Atlassian account should be editable in the org. admin UI
4. Update the Atlassian account email address to something unique, such as user_duplicate@example.domain
5. Run a provision on demand in Entra ID

This is covered in another KB: https://confluence.atlassian.com/cloudkb/409-error-when-attempting-to-update-email-address-via-user-provisioning-1035734019.html

Scenario 2

If the provisioning sync has created a new Atlassian account for the end user and did not update the user's existing Atlassian account, please check that:

• The end user's original Atlassian account is managed on your Atlassian organization. To confirm, search for the user in the Directory  > Managed accounts  page on your Atlassian organization. If the user's account is present, then it is a managed account
• The target email domain(if changing) is claimed by the same organization where the end user's Atlassian account is managed

The provisioning sync will not update Atlassian accounts that are not managed on the Atlassian organization and any attempts by an admin to remove and re-sync the user in the IdP will likely cause an Atlassian account duplication where the end user has a new empty Atlassian account created instead of the expected Atlassian account being updated

If the end user's Atlassian account:

• Is managed on the organization AND
• The target domain is claimed on the same Atlassian organization OR the end user's email domain is staying the same(not changing)

Then, please see below:

1. Delete the end user's provisioning record using this API: https://developer.atlassian.com/cloud/admin/user-provisioning/rest/api-group-admin-apis/#api-admin-user-provisioning-v1-org-orgid-user-aaid-onlydeleteuserindb-delete 
   If the end user is a member of any synced groups, then they will lose membership to those groups when the user is re-synced. After deleting the user's provisioning record, please remove group membership(s) to any groups the end user is a member of in the IdP. If the end user is a member of any dynamic groups, then the end user would need to be excluded from the dynamic group scope
2. This action will make the end user's new Atlassian account editable in the org. admin UI
3. Navigate to the end user's managed Atlassian account profile: Directory  > Managed accounts - search for the user and select the user's account
4. Edit the email address on the account to something unique but on the same email domain - the new email doesn't need to be a real email address, e.g. userNewEmail@domain.example will become userNewEmail_duplicate@domain.example
5. Locate the end user's managed Atlassian account - which should be on the "old"(previous) email address
6. Update the Atlassian account on the "old" account to the intended/target email address - e.g. userNewEmail@domain.example
7. Add the user back to the relevant groups in the IdP(if applicable)
8. Re-sync the user from the IdP - the end user's "old" Atlassian account should now be "locked" for editing due to the provisioning sync