• 548
    • 16
    • 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.

       

      Implementation of New Features Policy

       At the moment, we can't set an ETA for this feature to be released, since there's a number of factors that determine how our product team prioritizes new features. Consider adding yourself as a watcher to be kept informed as to the state of this feature request moving forward. With that way, if our development team updates the ticket, you'll be notified via email.
      You can learn more by reading Implementation of New Features Policy.

      Product team update 23 April 2022

      Although we understand the value of this feature, we do not have a short term timeline for its delivery. The main reason for this is there are dependent projects that need to be completed first.

      I recently published a blog looking at our customer management vision https://community.atlassian.com/t5/Jira-Service-Management-articles/Choosing-the-right-approach-to-Customer-Management-in-Jira/ba-p/1970761. I hope to be in a position to prioritise this feature in the next horizon of this vision. It is definitely amongst the top requirements for External Customers.

      I will update again at the end of the year, or if anything changes.

      Problem Definition

      There's no easy way to change the customer's email address.

      Suggested Solution

      For the Jira Service desk administrators to have the ability to change the customer's e-mail address and retain all the issues that is in progress.

      Workaround

      Try migrating the customer account to "Atlassian account":

      1. Login as a site-admin
      2. Operate migrate to Atlassian account for the portal customer account in question
      3. Optional: maybe you want to disable the product access for the account. But make sure to keep Has access on site enabled.

      With that, now the user can change the email address at https://id.atlassian.com/manage-profile/email.

      Besides, consider adding yourself as a watcher to be kept informed as to the state of this feature request moving forward. With that way, if our development team updates the ticket, you'll be notified via email.

       

            [JSDCLOUD-5746] Change the customer e-mail address

            Scott Fannen added a comment -

            3867f58dddae I'm not an expert at this (we didn't bother to migrate customers or change their email addresses as it was too much work) - but when you migrate the "customer" to an Atlassian account, you get an Atlassian user in Atlassian Admin that is "Active" but has no "chargeable products" (they have "Jira Service Management" "Customer product role" but that doesn't charge you). This option is a workaround for previous Jira license holders that are returning to be "just a customer" too (disable their products, not the whole user).

            In theory, at that point, IF you have domain admin (an escalated version of admin) where you can see "Managed Accounts" you can use that - not normal Atlassian Admin - to change the email address on the account (getting access to "Managed Accounts" if you haven't got it already isn't always the easiest thing either). 

            Unfortunately even then, there's no bulk admin, and something you may bump into is if the user has attempted to log in using their "new email", that may be in the system too - which will block you from changing the email address (this applies to normal Atlassian paid product users too) of the old Atlassian account.

            That is - if you try to change marc@oldacme.org to marc@newacme.org , and marc@newacme.org exists, the system will say no. 

            Then you need to check if marc@newacme.org exists legitimately somewhere else - so looking in Managed Accounts for that email, and seeing if it's used for some other Atlassian product like Trello or Bitbucket.

            If NOT, then you can delete the "dodgy new account" which has no products (which sends a scary warning to the user which makes them panic - so you may want to warn them in advance to ignore that, if you do), wait two weeks (as it doesn't delete straight away), and then change the email on the old account finally.

            If it IS used legitimately somewhere else, then you're a bit stuck - where you may end up having to disable the old user and set them up in Jira and/or Confluence again with the same permissions as the old one - which for a customer-only account defeats the purpose of the whole exercise (as they'll lose access to their old calls anyway - and in the case of Jira licensed users, they'll lose access to calls, queries, dashboards, etc that they may have had on the old account). Note also that while you can "fix" a lot of things for Jira licensed users by changing ownership or doing bulk edits, Jira still doesn't let you bulk edit Request Participants (another call we're waiting for) - which effects Jira Service Management in a huge way

            Also it isn't great if your organisation is doing a gradual migration of email accounts - because I think while there's some way to use the API to bulk change things in Atlassian that's not helpful if you're not sure if the user has updated their email or not (without manually checking the email directory one by one). 

            So to summarise, migrating to an Atlassian account will not cost you a new license (yay), but it still won't get you bulk edit, and unless you can get to "Managed Accounts" you won't be able to change the email anyway - and it will be VERY PAINFUL. Sorry. 

            Scott Fannen added a comment - 3867f58dddae I'm not an expert at this (we didn't bother to migrate customers or change their email addresses as it was too much work) - but when you migrate the "customer" to an Atlassian account, you get an Atlassian user in Atlassian Admin that is "Active" but has no "chargeable products" (they have "Jira Service Management" "Customer product role" but that doesn't charge you). This option is a workaround for previous Jira license holders that are returning to be "just a customer" too (disable their products, not the whole user). In theory, at that point, IF you have domain admin (an escalated version of admin) where you can see "Managed Accounts" you can use that - not normal Atlassian Admin - to change the email address on the account (getting access to "Managed Accounts" if you haven't got it already isn't always the easiest thing either).  Unfortunately even then, there's no bulk admin, and something you may bump into is if the user has attempted to log in using their "new email", that may be in the system too - which will block you from changing the email address (this applies to normal Atlassian paid product users too) of the old Atlassian account. That is - if you try to change marc@oldacme.org to marc@newacme.org , and marc@newacme.org exists, the system will say no.  Then you need to check if marc@newacme.org exists legitimately somewhere else - so looking in Managed Accounts for that email, and seeing if it's used for some other Atlassian product like Trello or Bitbucket. If NOT, then you can delete the "dodgy new account" which has no products (which sends a scary warning to the user which makes them panic - so you may want to warn them in advance to ignore that, if you do), wait two weeks (as it doesn't delete straight away), and then change the email on the old account finally. If it IS used legitimately somewhere else, then you're a bit stuck - where you may end up having to disable the old user and set them up in Jira and/or Confluence again with the same permissions as the old one - which for a customer-only account defeats the purpose of the whole exercise (as they'll lose access to their old calls anyway - and in the case of Jira licensed users, they'll lose access to calls, queries, dashboards, etc that they may have had on the old account). Note also that while you can "fix" a lot of things for Jira licensed users by changing ownership or doing bulk edits, Jira still doesn't let you bulk edit Request Participants (another call we're waiting for) - which effects Jira Service Management in a huge way Also it isn't great if your organisation is doing a gradual migration of email accounts - because I think while there's some way to use the API to bulk change things in Atlassian that's not helpful if you're not sure if the user has updated their email or not (without manually checking the email directory one by one).  So to summarise, migrating to an Atlassian account will not cost you a new license (yay), but it still won't get you bulk edit, and unless you can get to "Managed Accounts" you won't be able to change the email anyway - and it will be VERY PAINFUL. Sorry. 

            Marc Muhlestein added a comment -

            When you migrate a portal only customer to a migrated account, will it keep the setup as customer?  I don't want to pay a license for them in Jira.  They need portal only access and I need to change their email address for the same reason?  Also, bulk edit would be nice too.  

            We use Jira Customers for internal as well.  We have 250+branches that we support nationwide and use Jira for our ticketing.  I only want my branch guys to have access to the portal so I added them all as customers.  Now we rebranded and have a different domain name that I want to update them all to.  I can't do that and can't find an API setup that shows how to bulk edit them. All I need to do is change the domain part of the email address.  So, if migrating them to an Atlassian account is the right way, 1. does that keep them as customer only and 2. can that be bulk edited at that point to change the email address?   Otherwise it's migrate, then open each one again and update the email address.  That is close to 1500 emails.  Insights or direction on where I can turn for answers?  

            Marc Muhlestein added a comment - When you migrate a portal only customer to a migrated account, will it keep the setup as customer?  I don't want to pay a license for them in Jira.  They need portal only access and I need to change their email address for the same reason?  Also, bulk edit would be nice too.   We use Jira Customers for internal as well.  We have 250+branches that we support nationwide and use Jira for our ticketing.  I only want my branch guys to have access to the portal so I added them all as customers.  Now we rebranded and have a different domain name that I want to update them all to.  I can't do that and can't find an API setup that shows how to bulk edit them. All I need to do is change the domain part of the email address.  So, if migrating them to an Atlassian account is the right way, 1. does that keep them as customer only and 2. can that be bulk edited at that point to change the email address?   Otherwise it's migrate, then open each one again and update the email address.  That is close to 1500 emails.  Insights or direction on where I can turn for answers?  

            Alberto Y added a comment -

            Not only is this needed for admin. There should also be an option to bulk update them. I have many companies under my instance that have rebranded and it's impossible to update their email while keeping the ticket history.

            Alberto Y added a comment - Not only is this needed for admin. There should also be an option to bulk update them. I have many companies under my instance that have rebranded and it's impossible to update their email while keeping the ticket history.

            Don't worry 75f3e0bc41b1. We got an update 2 years ago! That should keep us going for another 2 years at least...

            Perhaps then we will get an ETA on this basic feature.

            As you can tell, we are pretty disappointed with the lack of interaction from the product team on what I would consider one of the features that have a large following. 

            We also represent an organisation that has 1000s of users who are undergoing a gradual, country by country domain change which is an extremely jarring process because of this limitation. 

             

            Robert Dyson added a comment - Don't worry 75f3e0bc41b1 . We got an update 2 years ago! That should keep us going for another 2 years at least... Perhaps then we will get an ETA on this basic feature. As you can tell, we are pretty disappointed with the lack of interaction from the product team on what I would consider one of the features that have a large following.  We also represent an organisation that has 1000s of users who are undergoing a gradual, country by country domain change which is an extremely jarring process because of this limitation.   

            Hello Atlassian... I add my voice to my fellow paying Atlassian Users and Administrators here!  And more than that, I echo the voices of the MANY, MANY, MANY end-users who are impacted by this system-limitation. (Not to mention the voiceless costs impacting our businesses, our productivity, reputation, etc.)

            Please keep in mind – there are currently 669 votes on this issue. If each of these votes represent 500+ users (like in my instance – I vote on behalf of my 600 paid users & our 4900 unique JSM "Customers" ) then we're looking at (a minimum) between 334,500-3,000,000+ users potentially being impacted by this limitation. 

            *NOTE: I hope you'll please keep this in mind for ALL or our open Atlassian tickets! Every vote counts x1000 !!!!
            *

            With respect, I thank you,

            Mark

            Mark B Wager added a comment - Hello Atlassian... I add my voice to my fellow paying Atlassian Users and Administrators here!  And more than that, I echo the voices of the MANY, MANY, MANY end-users who are impacted by this system-limitation. (Not to mention the voiceless costs impacting our businesses, our productivity, reputation, etc.) Please keep in mind – there are currently 669 votes on this issue. If each of these votes represent 500+ users (like in my instance – I vote on behalf of my 600 paid users & our 4900 unique JSM "Customers" ) then we're looking at (a minimum) between 334,500-3,000,000+ users potentially being impacted by this limitation.   *NOTE: I hope you'll please keep this in mind for ALL or our open Atlassian tickets! Every vote counts x1000 !!!! * With respect, I thank you, Mark

            We had a recent issue that their account/email was set up as a their legal name instead of preferred and we're stuck on not being able to change it.

             

            Thankfully they don't currently have a large amount of data and can work around, but it's inconvenient.

            Derek Fitzgerald added a comment - We had a recent issue that their account/email was set up as a their legal name instead of preferred and we're stuck on not being able to change it.   Thankfully they don't currently have a large amount of data and can work around, but it's inconvenient.

            Nicolas PR added a comment -

            We are currently using server instances and we manage our users' accounts, including managing their names, emails, and other metadata. However, we are facing challenges with the migration to the cloud, particularly concerning this aspect.

            This issue is of critical importance to us, and we need to find a solution or workaround as soon as possible. The ability to edit JSM customer emails through the GUI or API on the cloud instances is crucial for our operations.

            Nicolas PR added a comment - We are currently using server instances and we manage our users' accounts, including managing their names, emails, and other metadata. However, we are facing challenges with the migration to the cloud, particularly concerning this aspect. This issue is of critical importance to us, and we need to find a solution or workaround as soon as possible. The ability to edit JSM customer emails through the GUI or API on the cloud instances is crucial for our operations.

            Hey Atlassian - I note that this issue is now been outstanding for almost six years, not only that but looking at the history it would suggest that this is a bug that didn't exist back in May 2017 and was therefore introduced as one of your 'upgrades'.  How long does it take you to fix bug's like this?  I've just come across it for the first time, but this will now obviously cause problems when someone changes their email address.  Poor.

            Keith Saunders added a comment - Hey Atlassian - I note that this issue is now been outstanding for almost six years, not only that but looking at the history it would suggest that this is a bug that didn't exist back in May 2017 and was therefore introduced as one of your 'upgrades'.  How long does it take you to fix bug's like this?  I've just come across it for the first time, but this will now obviously cause problems when someone changes their email address.  Poor.

            Why have 'portal only' customer accounts as an option then??  If we have to make them Jira users to actually be able to manage them, then just make them Jira users to begin with.  You are overcomplicating so much functionality!

            Troy Anderson added a comment - Why have 'portal only' customer accounts as an option then??  If we have to make them Jira users to actually be able to manage them, then just make them Jira users to begin with.  You are overcomplicating so much functionality!

            I don´t undestand Atlassian's prioritization system. We have Jira for 1 year and I have encountered so many years old cases that would be...no... that are basically must have! Yet Atlassian keeps publishing new features we have no use for.

            Dominik Březina added a comment - I don´t undestand Atlassian's prioritization system. We have Jira for 1 year and I have encountered so many years old cases that would be...no... that are basically must have! Yet Atlassian keeps publishing new features we have no use for.

              a1217920d496 Ash Young
              24b81c5fdefd Jerome Mark Wee
              Votes:
              692 Vote for this issue
              Watchers:
              419 Start watching this issue

                Created:
                Updated: