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

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

XMLWordPrintable

    • 5,690

    • 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

            Ankit Patel added a comment -

            +100

            Ankit Patel added a comment - +100

            Sheetal Gajra added a comment -

            https://getsupport.atlassian.com/browse/PCS-333864

            Sheetal Gajra added a comment - https://getsupport.atlassian.com/browse/PCS-333864

            Yev added a comment -

            Please allow option to completely deactivate Jira internal user management and allow ADFS or Entra to take over ALL authentication functionality.

            Jira's user management design is completely inadequate to say the least.

            Multiple features such as SSO and provisioning are basically useless when the core design is not actually practical.

            Very bad project management – you are adding features to something that doesn't work to begin with (in the sense that customers are actually satisfied with simple user management – which nobody is honestly).

            Yev added a comment - Please allow option to completely deactivate Jira internal user management and allow ADFS or Entra to take over ALL authentication functionality. Jira's user management design is completely inadequate to say the least. Multiple features such as SSO and provisioning are basically useless when the core design is not actually practical. Very bad project management – you are adding features to something that doesn't work to begin with (in the sense that customers are actually satisfied with simple user management – which nobody is honestly).

            Cory Zerwas added a comment -

            We still would like to have functionality to combine duplicate accounts outside of migration.
            For instance, a user goes through a name change and that updates their email address. Now they continue using our federated Atlassian platform and accidentally created a new account by doing so.
            We need the ability to combine their two accounts, or move the profile data from the old account into the new account. I do know about the trick to correct this by changing the email address of the new account to a temporary value then updating the old account but that isn't particularly useful when the user has been using their new account for a few weeks, establishing links to pages and issues with it, and would like to keep the data from both accounts intact during the combination of the two.

            Cory Zerwas added a comment - We still would like to have functionality to combine duplicate accounts outside of migration. For instance, a user goes through a name change and that updates their email address. Now they continue using our federated Atlassian platform and accidentally created a new account by doing so. We need the ability to combine their two accounts, or move the profile data from the old account into the new account. I do know about the trick to correct this by changing the email address of the new account to a temporary value then updating the old account but that isn't particularly useful when the user has been using their new account for a few weeks, establishing links to pages and issues with it, and would like to keep the data from both accounts intact during the combination of the two.

            Fergal O'Neill added a comment -

            Hi b034a8167584,

            If I had to guess, I would say that no one following this issue will be helped by the migration capability as we're all already migrated to the cloud. This has probably been posted a million times already, as it's a very obvious idea, but here's a design on how to do this:

            Create a "Merging users" page that displays two users side by side, you select which user will be the primary user that data from both users will be moved to. The page displays, side by side, a list of all settings currently applied to each user and lets you select which of the two settings to keep. You could even add the option to select a completely different setting if neither users setting makes sense after merging. Included in this would be the other tenants that the users are both a part of, as this would need to be merged as well.

            Most likely, the tenant performing the merge would need to own both users for this to work, but I think that's an acceptable limitation.

            When an admin completes the process, you update the database to point all user data at the primary user, and update the settings for the primary user to match the selection made by the admin on the "Merging Users" page. The secondary user is then disabled, and possibly deleted as it should no longer have any data associated with it.

            Logs would also have to be merged to the primary user and would need a note on them to indicate the log comes from a secondary user and the email of the secondary user should be present in the note.

            I'm sure there's probably some reason this hasn't been done already, but it would be great if you told us what that reason was, and put it in the issue description so that we don't have to read through years of comments to find it.

            Hoping you implement this soon.

            Fergal O'Neill added a comment - Hi b034a8167584 , If I had to guess, I would say that no one following this issue will be helped by the migration capability as we're all already migrated to the cloud. This has probably been posted a million times already, as it's a very obvious idea, but here's a design on how to do this: Create a "Merging users" page that displays two users side by side, you select which user will be the primary user that data from both users will be moved to. The page displays, side by side, a list of all settings currently applied to each user and lets you select which of the two settings to keep. You could even add the option to select a completely different setting if neither users setting makes sense after merging. Included in this would be the other tenants that the users are both a part of, as this would need to be merged as well. Most likely, the tenant performing the merge would need to own both users for this to work, but I think that's an acceptable limitation. When an admin completes the process, you update the database to point all user data at the primary user, and update the settings for the primary user to match the selection made by the admin on the "Merging Users" page. The secondary user is then disabled, and possibly deleted as it should no longer have any data associated with it. Logs would also have to be merged to the primary user and would need a note on them to indicate the log comes from a secondary user and the email of the secondary user should be present in the note. I'm sure there's probably some reason this hasn't been done already, but it would be great if you told us what that reason was, and put it in the issue description so that we don't have to read through years of comments to find it. Hoping you implement this soon.

            Martyn Beaumont added a comment - - edited

            Great, thanks Akshay.

            We still need the ability to merge accounts in place too.

            Martyn Beaumont added a comment - - edited Great, thanks Akshay. We still need the ability to merge accounts in place too.

            Kirstin Seidel-Gebert added a comment -

            Hi Akshay,

            for us this is not only a migration issue. We already have migrated.
            I now have colleagues that have a (new) Atlassian account as a result of the migration, but they already had an Atlassian account at another company (one of our clients). These colleagues cannot easily switch between instances, they need to use workarounds like logging in and out or using different browsers for different instances.

            Kirstin Seidel-Gebert added a comment - Hi Akshay, for us this is not only a migration issue. We already have migrated. I now have colleagues that have a (new) Atlassian account as a result of the migration, but they already had an Atlassian account at another company (one of our clients). These colleagues cannot easily switch between instances, they need to use workarounds like logging in and out or using different browsers for different instances.

            Akshay Johri added a comment -

            Hi. We had shipped the capability to Merge, Deduplicate or Deactivate users during migration using the Migration Assistants.
            Community Post: https://community.atlassian.com/t5/Atlassian-Migration-Program/Merge-update-or-deactivate-users-during-your-transition-to-Jira/ba-p/2782592

            Please try it and share your feedback. We're also looking at suggesting accounts with same username (but different email addresses) as duplicate accounts. Do you think it would be useful?

            Akshay Johri added a comment - Hi. We had shipped the capability to Merge, Deduplicate or Deactivate users during migration using the Migration Assistants. Community Post : https://community.atlassian.com/t5/Atlassian-Migration-Program/Merge-update-or-deactivate-users-during-your-transition-to-Jira/ba-p/2782592 Please try it and share your feedback. We're also looking at suggesting accounts with same username (but different email addresses) as duplicate accounts. Do you think it would be useful?

            Carla Norman added a comment -

            One good thing to note is that when one account is brand new and has no data associated with it, the existing account can be renamed to the new account.  

            Ex) Sheena@company.com 

            Claim the new domain which we will call enterprise.com 
            You can then change sheena@company.com to sheena@enterprise.com.
            You can also claim domains in more that one organization now so this will help the situation.

            Carla Norman added a comment - One good thing to note is that when one account is brand new and has no data associated with it, the existing account can be renamed to the new account.   Ex) Sheena@company.com   Claim the new domain which we will call enterprise.com  You can then change sheena@company.com to sheena@enterprise.com. You can also claim domains in more that one organization now so this will help the situation.

            Robert DaSilva - Adaptavist added a comment - - edited

            I think one way that merging accounts can be implemented is on a per-organization basis, limited to accounts where the domain has been verified. 

            One frequent challenge we run into is with clients performing acquisitions. They have a number of users under one account domain (@domain1.com), and end up creating brand new accounts under the new company name (@domain2.com). In this situation, all historical content under the first domain (@domain1.com) would merge with the second, newer account (@domain2.com).

            Having this limited to only accounts that are currently managed and verified would reduce the risk of merging accounts that may be outside the organisation's jurisdiction.

            Robert DaSilva - Adaptavist added a comment - - edited I think one way that merging accounts can be implemented is on a per-organization basis, limited to accounts where the domain has been verified.  One frequent challenge we run into is with clients performing acquisitions. They have a number of users under one account domain (@domain1.com), and end up creating brand new accounts under the new company name (@domain2.com). In this situation, all historical content under the first domain (@domain1.com) would merge with the second, newer account (@domain2.com). Having this limited to only accounts that are currently managed and verified would reduce the risk of merging accounts that may be outside the organisation's jurisdiction.

              Unassigned Unassigned
              4d9822a9db55 Dave Liao
              Votes:
              2578 Vote for this issue
              Watchers:
              1345 Start watching this issue

                Created:
                Updated: