Unable to push user from the Identity Provider through user provisioning with Atlassian Guard
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Unable to push user email change from the Identity Provider (IdP) into the Atlassian organization with Atlassian Guard.
Environment
Atlassian Cloud products
Atlassian Guard
Diagnosis
Resource [USER]: with email[name@domain.com] already exists.Cause
This happens when an account is provisioned with emailA@domain.com from the IdP and later the email is changed within the IdP to emailB@domain.com but there is already another Atlassian account using the email.
This other Atlassian account might have been created by the user on self sign-up or site administrator through invitation, for example.
Additionally, mismatched attribute mappings between SSO and SCIM configuration, such as using different identifiers (like `user.mail` and `user.userprincipalname`), can cause discrepancies, synchronization errors, and duplicate accounts.
Solution
Resolving email conflicts during user provisioning
To resolve email conflicts and avoid duplicate accounts during user provisioning or email/domain migrations, follow these steps:
Identify the conflicting Atlassian account Find the Atlassian account currently using the email address you want to assign to another user.
Change the email of the conflicting account Update the email address of the conflicting account to a placeholder (for example,
emailB+duplicated@domain.com) using the Managed Accounts page or by contacting Atlassian support. This action frees up the desired email address for reassignment.Update the IdP mapping Adjust the email attribute mapping in your IdP (such as Azure AD, Okta, etc.) to reflect the desired email change.
Push the update from the IdP Trigger a synchronization or push the update from your IdP to Atlassian to assign the desired email to the correct account.
Delete SCIM records if needed If synchronization issues persist, delete SCIM records for affected users to ensure proper synchronization during the next provisioning cycle.
Handle unmanaged accounts For unmanaged accounts, claim the accounts and verify their domains before attempting synchronization.
Verify and claim domains during migrations If your organization is migrating to a new email domain, verify and claim both the old and new domains within your Atlassian organization to manage account transitions seamlessly.
Best Practices:
Avoid late-stage manual changes in Atlassian for IdP-managed accounts; always make changes through your IdP and use automated provisioning.
Ensure SSO and SCIM attribute mappings (such as
user.mailoruser.userprincipalname) are consistent to prevent synchronization errors and duplicate accounts.Proactively review and suspend outdated or external accounts during domain transitions to prevent inconsistencies.
Resources
Was this helpful?