How changing domain of email address affects Atlassian usage

[Barbara Szczesniak]

My company is changing the domain of our email addresses from @meetingprotocol.com to @scoutclinical.com. Of course, emails sent to the former address will still be received.

Since I use my email address to access Atlassian Community and Jira, as well as our cloud, I am wondering how this change will affect this access. 

I just checked, and my Atlassian account is managed by my Admin, so I guess they will need to change the email address associated with my account. When they do this, will I keep my history, bookmarks, Kudos (made it to 15K), etc.?

I'm also hoping that this change will be transparent for my account within our Jira and Confluence clouds.

[Nic Brough -Adaptavist- · Accepted solution]

Hi Barbara,

Yes, you should be fine.  Your data is all tied to the account, not the email on the account.  Changing the email will not affect anything.

[Ed Letifov _TechTime - New Zealand_ · Accepted solution]

Hello, @Barbara Szczesniak 

"Managed by admin" means your old email domain and thus your account has been "claimed" by your organisation. You can't change the email yourself (thus effectively leaving your organisation) but the admin of that org – indeed can. If they have to update the emails of their users in bulk, I genuinely pity them. Hopefully they know how to write a script working via REST API.

If they change your email, and you login with the new one – everything else stays linked, as it is keyed to the account id, not the email address. Just as @Nic Brough -Adaptavist- said.

However, usually what follows after domain verification and accounts claim is a setup of the integration with the Identity Provider, usually for SAML SSO, but also for automatic user provisioning e.g. from your Azure AD/Entra ID to Atlassian Cloud.

In this case the change of the email needs to be done on your IdP side e.g. Azure AD/Entra ID and it should then be propagated to Cloud automatically.

And here comes the "catch" – everything will be fine, IF it all is configured correctly. And this, alas, is not a given.

In the case of Azure AD/Entra ID, the documentation published (by Atlassian?) to the Microsoft documentation site completely omits a very important detail about setting "Matching Precedence" correctly and could, and indeed has been, misunderstood by the admins. And to complicate this, the default value of that being set to the "User Principal Name" is wrong too in a general enterprise use case, since UPNs can change – it should instead be the Object ID.

So really... I suggest you point your admin to this response, and keep your 🤞

[Barbara Szczesniak]

Thank you, @Ed Letifov _TechTime - New Zealand_ I will let my admin know about this.