Uploaded image for project: 'Identity'
  1. Identity
  2. ID-240

Ability to merge Atlassian accounts to a single account with secondary emails

    • 6,152
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Update 2021-06-23

      Hi everyone,

      Thank you for your patience and continual feedback on this issue.

      We wanted to share an update on this ticket for everyone who has been understandably frustrated about the status of this functionality. We hear you. As a team, we discuss this request and how we might be able to address it several times a year. But ultimately, the delay comes down to how complex this problem is and how many teams are involved to get to a working solution.

      Thanks to your input though, especially from those who have been involved in our interviews, we’ve been able to break down your requests into areas we can iteratively improve, which in full transparency, is the most effective way for us to resource and tackle this ask.

      Here’s what we’re currently working on:

      • An improved account switcher that will allow you to work more seamlessly across your multiple accounts, without having to constantly log out and log back in. We are expecting to start development on this next quarter so keep your eyes peeled.
        Improving the way you clean up and remove duplicate accounts (bulk deactivation).
      • Identifying and improving the workflows that lead to accidental duplicate account creation in the first place.

      We understand that for some of you, these changes above still don’t address the core issue - being able to consolidate everything into just one identity. We are actively discussing with all of our product teams what is feasible here. To offer some insight into why this is not an easy problem for us to solve: we need to ensure that all content (comments, pages, issues, links etc.) continue to be valid under the correct owner, permissions appropriately transferred, and privacy and security settings respected.

      To be completely transparent, it is unlikely that we will reach a solution where all data in multiple Atlassian accounts across 20+ services can ever be combined, but we absolutely want to make this a better experience for our customers compared to what it is today.

      We’ll continue to post updates here on the changes we’re making to improve the experience for everyone with multiple accounts. Thanks again for your patience as we work through this request.

      Problem Definition

      When there are several Atlassian accounts, it is not possible to change the email address because both email addresses are in used.

      Suggested Solution

      Allow the ability to merge Atlassian accounts.

      Why this is important

      • The purpose of Atlassian to allow users to log in to any Atlassian Cloud products with the same email address. However, without merging the accounts, it's still partially met the purpose.
        • It is not convenient for users to log into different Atlassian Cloud instances with different Atlassian Accounts

      Workaround

      There is no workaround at the moment to merge data for multiple Atlassian accounts:

            [ID-240] Ability to merge Atlassian accounts to a single account with secondary emails

            Pinned comments

            Pinned by Kat N

            Akshay Johri added a comment -

            Hi. I’m Akshay, a Product Manager at Atlassian.

            We’ve introduced a new capability in the Jira Cloud Migration Assistant (JCMA) and Confluence Cloud Migration Assistant (CCMA) that helps manage your user base during a cloud transition. When running a migration, and trying to fix your user base, you can perform all complex changes in one go, by downloading the list of all users as a CSV. You can:

            • Merge users: Combine duplicate accounts.
            • Update email addresses: Correct any invalid email addresses.
            • Deactivate users: Disable user accounts that are no longer required after migrating.

            Read more: https://support.atlassian.com/migration/docs/customize-your-users-in-advanced-experience/

            Akshay Johri added a comment - Hi. I’m Akshay, a Product Manager at Atlassian. We’ve introduced a new capability in the Jira Cloud Migration Assistant (JCMA) and Confluence Cloud Migration Assistant (CCMA) that helps manage your user base during a cloud transition. When running a migration, and trying to fix your user base, you can perform all complex changes in one go, by downloading the list of all users as a CSV. You can: Merge users : Combine duplicate accounts. Update email addresses : Correct any invalid email addresses. Deactivate users : Disable user accounts that are no longer required after migrating. Read more: https://support.atlassian.com/migration/docs/customize-your-users-in-advanced-experience/

            All comments

            Dave Liao added a comment -

            You're right Dusty. The thought is that ID-6403 would prevent the need to perform certain merge operations - say, if you were a MegaCorp that already knows you maintain identities for users across several domains:

            • user1@luna.megacorp.com
            • user1@megacorp.com
            • user2@megacorp.com
            • user2@phobos.megacorp.com

            It'd make working in JSM nicer.

            Dave Liao added a comment - You're right Dusty. The thought is that ID-6403 would prevent the need to perform certain merge operations - say, if you were a MegaCorp that already knows you maintain identities for users across several domains: user1@luna.megacorp.com user1@megacorp.com user2@megacorp.com user2@phobos.megacorp.com It'd make working in JSM nicer.

            Hi 4d9822a9db55 

            While having multiple emails per account is a great feature, it doesn't solve the core issue of merging multiple accounts. This could only be solved by combining permissions, groups, product access, assignee, reporter, watched issues/pages, and any other user specific user item. 

            I'm currently combining five various companies into one cloud instance, and they all have separate emails. Above half of these accounts I was able to change the email address on the account to the new company email, but the other half was given our new company's email address before I was brought onboard. That created the issue of them having access to the new site and working with their account that is tied to their new email and their old account which has access to their old cloud or on-prem site. 

            Having JCMA convert users is nice, but it doesn't fully solve the issue since it doesn't combine two Atlassian Cloud accounts (unless I'm understanding something incorrectly. Since there isn't a solution at all for cloud-to-cloud migrations, we really don't have any workaround for the issue. 

            Dusty Brossart added a comment - Hi 4d9822a9db55   While having multiple emails per account is a great feature, it doesn't solve the core issue of merging multiple accounts. This could only be solved by combining permissions, groups, product access, assignee, reporter, watched issues/pages, and any other user specific user item.  I'm currently combining five various companies into one cloud instance, and they all have separate emails. Above half of these accounts I was able to change the email address on the account to the new company email, but the other half was given our new company's email address before I was brought onboard. That created the issue of them having access to the new site and working with their account that is tied to their new email and their old account which has access to their old cloud or on-prem site.  Having JCMA convert users is nice, but it doesn't fully solve the issue since it doesn't combine two Atlassian Cloud accounts (unless I'm understanding something incorrectly. Since there isn't a solution at all for cloud-to-cloud migrations, we really don't have any workaround for the issue. 

            Happy 10th birthday ID-240.🍺 !

            It's also coming up to a year since Atlassian has been able to combine accounts in JCMA + CCMA prior to migration.

            Has any of this learning been applied to handling users in the cloud?

            Since this has been in #topasks and Future Consideration for so long I would really expect the communication on this topic to be more regular / better.

            Dave Meredith added a comment - Happy 10th birthday ID-240 .🍺 ! It's also coming up to a year since Atlassian has been able to combine accounts in JCMA + CCMA prior to migration. Has any of this learning been applied to handling users in the cloud? Since this has been in #topasks and Future Consideration for so long I would really expect the communication on this topic to be more regular / better.

            Dave Liao added a comment -

            👋 I'm the original Reporter of this Suggestion, here to wish this ticket a happy 10th birthday.

            💡Did you know about ID-6403? I'd like to take a moment to steer everyone to ID-6403, which seems a lot easier for Atlassian to implement.

            To the 1,379 watchers[1] on this Suggestion, please raise a mug to ID-240.🍺

            p.s. If you see someone wearing an ID-240 t-shirt at Team '25 Europe, that's probably me.

            Dave Liao added a comment - 👋 I'm the original Reporter of this Suggestion, here to wish this ticket a happy 10th birthday . 💡 Did you know about ID-6403 ? I'd like to take a moment to steer everyone to ID-6403 , which seems a lot easier for Atlassian to implement. To the 1,379 watchers [1] on this Suggestion, please raise a mug to ID-240 .🍺 p.s. If you see someone wearing an ID-240 t-shirt at Team '25 Europe, that's probably me.

            Not having this ability means a lot of extra work on the admins and data reference loss, no matter what, as some things can't be mapped to a new user account (i.e. @ mentions, comments made, API tokens, etc). It would also be helpful if Atlassian provided a complete list to ensure none of the necessary mappings are overlooked. Going off the top of ones head for something like this will definitely lead to things being missed.

            Gary Spross added a comment - Not having this ability means a lot of extra work on the admins and data reference loss, no matter what, as some things can't be mapped to a new user account (i.e. @ mentions, comments made, API tokens, etc). It would also be helpful if Atlassian provided a complete list to ensure none of the necessary mappings are overlooked. Going off the top of ones head for something like this will definitely lead to things being missed.

            Maybe instead of doing pointless UI updates, Atlassian could address real pain points like the one in this ticket?

            John Potter added a comment - Maybe instead of doing pointless UI updates, Atlassian could address real pain points like the one in this ticket?

            Pallavi Biroli added a comment - https://getsupport.atlassian.com/browse/MOVE-1785415

            We are going migrating to Atlassian cloud this year (because we are practically being forced to) and this user management is going to really be a pain in the ass. Please do SOMETHING

            Aaron Matthys added a comment - We are going migrating to Atlassian cloud this year (because we are practically being forced to) and this user management is going to really be a pain in the ass. Please do SOMETHING

            Amanda Culver added a comment - - edited

            Your workaround doesn't cover

            Products Source user may be granted access to different Products than the Target user account, a 'merge' should ensure the Product access is also carried over

            Permissions granted to the Source user.

            • Permissions
              • where Source user is named in a permission scheme 
              • where Source user is named in the Global permissions (urgh)
            • Roles granted to the Source user in different projects
            • Where the Source user is the Project lead
            • Components where the Source user is the owner 

            Group Memberships (Source user is a member of GroupX > GroupX is named in a permission scheme/granted a role)

            it also doesn't cover replacing the Source user in any fields of type 'user name' (such as 'Approvers', 'Stakeholders', etc)

            It doesn't make reference to any Automations

            • Where the user is specifically mentioned (send an email to [Source user])
            • Where the user is the creator (and thus may receive emails when the automation fails)

            Teams that the Source user is in.

            API Tokens for the Source user

            Amanda Culver added a comment - - edited Your workaround doesn't cover Products Source user may be granted access to different Products than the Target user account, a 'merge' should ensure the Product access is also carried over Permissions granted to the Source user. Permissions where Source user is named in a permission scheme  where Source user is named in the Global permissions (urgh) Roles granted to the Source user in different projects Where the Source user is the Project lead Components where the Source user is the owner  Group Memberships (Source user is a member of GroupX > GroupX is named in a permission scheme/granted a role) it also doesn't cover replacing the Source user in any fields of type 'user name' (such as 'Approvers', 'Stakeholders', etc) It doesn't make reference to any Aut omations Where the user is specifically mentioned (send an email to [Source user] ) Where the user is the creator (and thus may receive emails when the automation fails) Teams   that the Source user is in. API Tokens for the Source user

            I'm working to combine multiple different companies into one and some users already have accounts with the new company email, an intermediate email, and their old email. It's very frustrating that we can't have the option to combine accounts. It makes enterprise management of accounts infuriating.

            Dusty Brossart added a comment - I'm working to combine multiple different companies into one and some users already have accounts with the new company email, an intermediate email, and their old email. It's very frustrating that we can't have the option to combine accounts. It makes enterprise management of accounts infuriating.

              Unassigned Unassigned
              4d9822a9db55 Dave Liao
              Votes:
              2672 Vote for this issue
              Watchers:
              1388 Start watching this issue

                Created:
                Updated: