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

Allow multiple email addresses to be associated with a single Atlassian account

    • 452
    • 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.

      Some users would like to designate several email addresses on their Atlassian account specifically for site-specific notifications. This allows them to have a single identity that they can use as they work with different organizations across their careers, instead of having to spin up separate accounts with distinct full name, avatar, and other settings for each engagement.

      This request is particularly popular with Bitbucket users, as this model is in use by some other popular dev tools products. In fact, this request is currently the 13th-highest voted issue for Bitbucket with nearly 500 votes and many comments that can be read here: https://bitbucket.org/site/master/issues/7038/custom-email-routing-bb-8197

      To add to this, most organizations have the concept of User principal name and email address. Where the UPN is used to login (example SSO) and the email address is used for communication. In JSM, this causes an issue as the user signs up using their UPN. However, to receive updates, they'll have to use their email address. 

            [ID-6403] Allow multiple email addresses to be associated with a single Atlassian account

            awilkes can you assign the ticket to an active colleague please? (Freddie Xavier is inactive)
            Our ENT EMEA customer DM is asking when this feature request is being pushed? 

            Alexandra Czuckowitz added a comment - awilkes can you assign the ticket to an active colleague please? (Freddie Xavier is inactive) Our ENT EMEA customer DM is asking when this feature request is being pushed? 

            +1 please ... this would be real handy!

            Yatish Madhav added a comment - +1 please ... this would be real handy!

            This would be really helpful for external accounts as we want only managed accounts through SCIM provisioning for login using, but user external to our company does not have mailboxes associated to those accounts and even if we created them, they would not read it as they are using other mailboxes from their own company for daily communication.

            All other option to provision external users with own company email does not allow to control the accounts and diable them at the end of the contract.
            It should not be too difficult to add a field "contact email" ..... once the ticket would be re-assigned to an active user

            HAEGELIN Sacha added a comment - This would be really helpful for external accounts as we want only managed accounts through SCIM provisioning for login using, but user external to our company does not have mailboxes associated to those accounts and even if we created them, they would not read it as they are using other mailboxes from their own company for daily communication. All other option to provision external users with own company email does not allow to control the accounts and diable them at the end of the contract. It should not be too difficult to add a field "contact email" ..... once the ticket would be re-assigned to an active user

            It's absurd this has been open for 8 years and nothing has been done about it. Surely it isn't so complex that it needs 8 full years to implement. 

            Jesse Mrozowski added a comment - It's absurd this has been open for 8 years and nothing has been done about it. Surely it isn't so complex that it needs 8 full years to implement. 

            b387e3a4ed72 I'm not arguing against your point, I'm simply adding a few details corroborating your "Jira is really poorly designed" remark

            Piotr Janik added a comment - b387e3a4ed72 I'm not arguing against your point, I'm simply adding a few details corroborating your "Jira is really poorly designed" remark

            There's definitely a linkage to an ID with Atlassian accounts. If you click on a user from within your admin area, there is a AAID (Atlassian Account ID) that is in the URL. I use this ID to run scripts to disconnect them from their IdP and change emails of managed accounts. There would need to be some sort of linkage in the DB between these IDs to merge accounts. I'd assume one would need to be declared as the primary ID for logging in as well. 

            Dusty Brossart added a comment - There's definitely a linkage to an ID with Atlassian accounts. If you click on a user from within your admin area, there is a AAID (Atlassian Account ID) that is in the URL. I use this ID to run scripts to disconnect them from their IdP and change emails of managed accounts. There would need to be some sort of linkage in the DB between these IDs to merge accounts. I'd assume one would need to be declared as the primary ID for logging in as well. 

            Alexandre Guedes added a comment - - edited

            Hi f2ccc5b587fe 

            I am neither a Jira specialist nor a database specialist, so I might be wrong here, and I apologize for that. However, my opinion is not what matters. What truly matters is why Atlassian has not fixed this yet. Even more concerning, why is such a crucial request still be handled as a "suggestion"? That doesn’t make sense.

            In my case, I have thousands of tickets handled every single day—approval requests, survey validations, ticket notifications, etc. My internal and external clients simply do not get notified when something happens with their issues, just because Atlassian believes this is not important.

            Do you see the point here? It is not about technical issues or limitations. It is worse. From my perspective, it is about designing and selling a good product for the clients.

            We are all on the same boat here and begging Atlassian to do a good job.

            Alexandre Guedes added a comment - - edited Hi f2ccc5b587fe   I am neither a Jira specialist nor a database specialist, so I might be wrong here, and I apologize for that. However, my opinion is not what matters. What truly matters is why Atlassian has not fixed this yet. Even more concerning, why is such a crucial request still be handled as a "suggestion"? That doesn’t make sense. In my case, I have thousands of tickets handled every single day—approval requests, survey validations, ticket notifications, etc. My internal and external clients simply do not get notified when something happens with their issues, just because Atlassian believes this is not important. Do you see the point here? It is not about technical issues or limitations. It is worse. From my perspective, it is about designing and selling a good product for the clients. We are all on the same boat here and begging Atlassian to do a good job.

            b387e3a4ed72 I don't know about ID, but in Jira Data Center there are no foreign keys defined in the (SQL) database. Data integrity is supervised programmatically by Jira, not by the RDBMS. And Jira's compatibility with both PostgreSQL (using sequences) and MySQL (using autoincrement) is kept by using the sequence_value_item table (columns: SEQ_NAME and SEQ_ID) instead of either RDBMS's native solution.
            You need to set up a separate DBMS, and you don't even get to use its full capabilities. When we used to work with YouTrack, it didn't have a relational database at all (there was some sort of embedded key-value database), but there was no home-dir/data-dir/database split either. Everything sat in a single directory, and you could back it up with a single built-in command...

            Piotr Janik added a comment - b387e3a4ed72 I don't know about ID, but in Jira Data Center there are no foreign keys defined in the (SQL) database. Data integrity is supervised programmatically by Jira, not by the RDBMS. And Jira's compatibility with both PostgreSQL (using sequences) and MySQL (using autoincrement) is kept by using the sequence_value_item table (columns: SEQ_NAME and SEQ_ID ) instead of either RDBMS's native solution. You need to set up a separate DBMS, and you don't even get to use its full capabilities. When we used to work with YouTrack, it didn't have a relational database at all (there was some sort of embedded key-value database), but there was no home-dir/data-dir/database split either. Everything sat in a single directory, and you could back it up with a single built-in command...

            Well, I just think Atlassian doesn’t really care about its customers.

            From a technical perspective, this is a very simple issue and even easier to fix. We’re talking about adding a new field in Jira—behind the scenes—to store email addresses and use it for communication.

            It seems like Jira is really poorly designed. The only explanation for this taking so long to be solved is that Jira likely uses email addresses as primary keys in the authentication database. If that’s the case, changing this key could cause several issues.

            Come on, how is anyone still using emails as primary keys for identifying users in 2025? A separate internal string should be used instead.

            Anyway, Jira is not cheap. Even if this were a complex issue, Atlassian has the money to solve it. But I seriously doubt whether they have the technical expertise to do so…

            Alexandre Guedes added a comment - Well, I just think Atlassian doesn’t really care about its customers. From a technical perspective, this is a very simple issue and even easier to fix. We’re talking about adding a new field in Jira—behind the scenes—to store email addresses and use it for communication. It seems like Jira is really poorly designed. The only explanation for this taking so long to be solved is that Jira likely uses email addresses as primary keys in the authentication database. If that’s the case, changing this key could cause several issues. Come on, how is anyone still using emails as primary keys for identifying users in 2025? A separate internal string should be used instead. Anyway, Jira is not cheap. Even if this were a complex issue, Atlassian has the money to solve it. But I seriously doubt whether they have the technical expertise to do so…

            This is becoming a HUGE issue for us as we're migrating 5 companies into 1. One company has already migrated into another company before the decision was made to move all 5 into 1, so we have users that have 2 Atlassian accounts that will need to be updated to one account with their new email. So, in essence, we need email@company1.com and email@company2.com to be one account under email@company3.com. It's going to be a painstaking process to get this manually figured out. It seems like such an easy concept to just have multiple email addresses per account, but I do know some issues take a lot of development. However, this should be a high priority with all the headaches it causes for customers. Stop focusing on AI and other features that don't give real world value and pay attention to what customers are asking for - add the features that are causing real life issues. 

            Dusty Brossart added a comment - This is becoming a HUGE issue for us as we're migrating 5 companies into 1. One company has already migrated into another company before the decision was made to move all 5 into 1, so we have users that have 2 Atlassian accounts that will need to be updated to one account with their new email. So, in essence, we need email@company1.com and email@company2.com to be one account under email@company3.com. It's going to be a painstaking process to get this manually figured out. It seems like such an easy concept to just have multiple email addresses per account, but I do know some issues take a lot of development. However, this should be a high priority with all the headaches it causes for customers. Stop focusing on AI and other features that don't give real world value and pay attention to what customers are asking for - add the features that are causing real life issues. 

            13 months since my original comment, same symptoms and same progress (none) from Atlassian. Echoing all of the recent commenters. This should be a feature and not require long-winded attempts at resolving through automation.

            Chad Klinefelter added a comment - 13 months since my original comment, same symptoms and same progress (none) from Atlassian. Echoing all of the recent commenters. This should be a feature and not require long-winded attempts at resolving through automation.

            I still don't understand why Atlassian is so deaf on this issue, it has been created almost 8 years ago for a relevant problem that affects a lot of their customers.

            Thanks also to their unsatisfactory customer support, we will most likely switch to another platform this year.

            Fabrizio La Rosa added a comment - I still don't understand why Atlassian is so deaf on this issue, it has been created almost 8 years ago for a relevant problem that affects a lot of their customers. Thanks also to their unsatisfactory customer support, we will most likely switch to another platform this year.

            826253891ba5 I am currently testing a system using automation and Assets to associate all users with a single object and then having all their associated Atlassian accounts as an attribute. The basic idea is that, regardless of the account used to create the ticket, all of their other accounts would be added to the "Request participant" field, so functionally they can interact with the ticket using any account they want. If it works, I will post a write-up on the Atlassian Community boards.

            Lindsay Bolan added a comment - 826253891ba5 I am currently testing a system using automation and Assets to associate all users with a single object and then having all their associated Atlassian accounts as an attribute. The basic idea is that, regardless of the account used to create the ticket, all of their other accounts would be added to the "Request participant" field, so functionally they can interact with the ticket using any account they want. If it works, I will post a write-up on the Atlassian Community boards.

            Josh Noren added a comment -

            Has anyone developed any decent workarounds for this? I thought about trying to use automation, but nothing worked. Is everyone just closing/merging tickets that get created?

            Josh Noren added a comment - Has anyone developed any decent workarounds for this? I thought about trying to use automation, but nothing worked. Is everyone just closing/merging tickets that get created?

            +1

            This would be a highly valuable feature for us as well.

            Alejandro Concepción Rodríguez added a comment - This would be a highly valuable feature for us as well.

            This would be nice because my org uses aliased email addresses for some users and it would be helpful to assign multiple emails to the same user.

            Jesse Mrozowski added a comment - This would be nice because my org uses aliased email addresses for some users and it would be helpful to assign multiple emails to the same user.

            Reinforcing some of the comments here, this addresses issues for very common cases when merges and acquisitions happen.

            We also have AD on-premises synchronized with Azure AD to provision accounts to JSM and part of those accounts don't have usernames that match with their email addresses (specially for third-party users).

            This is a must have for us and we find awkward not to have a feature allowing to add another email address to accounts.

            andre.castro added a comment - Reinforcing some of the comments here, this addresses issues for very common cases when merges and acquisitions happen. We also have AD on-premises synchronized with Azure AD to provision accounts to JSM and part of those accounts don't have usernames that match with their email addresses (specially for third-party users). This is a must have for us and we find awkward not to have a feature allowing to add another email address to accounts.

            It's a big vote from me too.

            We use Jira in our company, and we use Active Directory (on-prem synced to Entra).

            Usually, our users have usernames/UPNs that do not correspond with their email addresses, so for us, there is a need to have mail aliases for login (SSO).

            Also, some external users do not have a mailbox at all, so we need to have the ability to add an additional email account for the notifications to be sent.

            Varvaresos Angelos added a comment - It's a big vote from me too. We use Jira in our company, and we use Active Directory (on-prem synced to Entra). Usually, our users have usernames/UPNs that do not correspond with their email addresses, so for us, there is a need to have mail aliases for login (SSO). Also, some external users do not have a mailbox at all, so we need to have the ability to add an additional email account for the notifications to be sent.

            With merger & acquisitions and spinoffs commonplace, there are often scenarios where users will have multiple email addresses and need to log on the different systems with different emails. This is sometimes true for extended periods of time after such corporate events occur. The lack of the ability to associate multiple emails with a single account creates enormous operational inefficiencies for companies that go through such events.

            Scott Howard added a comment - With merger & acquisitions and spinoffs commonplace, there are often scenarios where users will have multiple email addresses and need to log on the different systems with different emails. This is sometimes true for extended periods of time after such corporate events occur. The lack of the ability to associate multiple emails with a single account creates enormous operational inefficiencies for companies that go through such events.

            Alex Hall added a comment -

            Similar to others, having the ability to force a user with multiple email addresses to log in using the correct address would help reduce headaches and steps for providing support.

            Some employees are assigned multiple addresses to start based on the organization they're working in. Many employees have first.last@company and first.m.last@company. And every employee as a alphanumeric ID that drives our SSO, which differ from their name. It'd be very helpful if we could define say, four different email addresses that would all log in to the exact account we want them to log into.

            Alex Hall added a comment - Similar to others, having the ability to force a user with multiple email addresses to log in using the correct address would help reduce headaches and steps for providing support. Some employees are assigned multiple addresses to start based on the organization they're working in. Many employees have first.last@company and first.m.last@company. And every employee as a alphanumeric ID that drives our SSO, which differ from their name. It'd be very helpful if we could define say, four different email addresses that would all log in to the exact account we want them to log into.

            My company continues to suffer in the exact same way as 820ef1cfdf61 mentioned.

            Chad Klinefelter added a comment - My company continues to suffer in the exact same way as 820ef1cfdf61 mentioned.

            Mike Moore added a comment -

            My company just turned on ITSM, and this is a big issue when getting replies into tickets via email.  Having multiple domains associated with a single user would solve all of the issues.  

            Mike Moore added a comment - My company just turned on ITSM, and this is a big issue when getting replies into tickets via email.  Having multiple domains associated with a single user would solve all of the issues.  

            Working with a client going through a merger and thus having a set of users with one set of Active Directory / Email accounts migrating to a different set; in the interim, they're still using both accounts which means that again they might, say, open a Service Desk ticket from their new email but their account is associated with their old email.

            Or if they've migrated to their new account for most purposes including JIRA, perhaps someone will CC them on a Service Desk ticket using their old email address (because it's what they're used to).

            For this client, the pain will slowly go away, because they will presumably move towards using the new account for everything and deprecate/remove the old account, but for now it's going to add to the friction.

            Geoffrey Wiseman added a comment - Working with a client going through a merger and thus having a set of users with one set of Active Directory / Email accounts migrating to a different set; in the interim, they're still using both accounts which means that again they might, say, open a Service Desk ticket from their new email but their account is associated with their old email. Or if they've migrated to their new account for most purposes including JIRA, perhaps someone will CC them on a Service Desk ticket using their old email address (because it's what they're used to). For this client, the pain will slowly go away, because they will presumably move towards using the new account for everything and deprecate/remove the old account, but for now it's going to add to the friction.

            It's big vote from me. We use Jira in our company - and we use Active Directory (on-prem synced to Azure AD/Entra) as our identity base.

            Usually our users has username/upn, that does not corresponds with their email address - so for us there is a need to have mail aliases for login (sso).

            Mitja Hrovatič added a comment - It's big vote from me. We use Jira in our company - and we use Active Directory (on-prem synced to Azure AD/Entra) as our identity base. Usually our users has username/upn, that does not corresponds with their email address - so for us there is a need to have mail aliases for login (sso).

            Any news on this feature request, is Atlassian willing to put it in development roadmap?

            It is very important for us because we use Jira to manage service requests coming from our users and they could use either their work or personal email address.

            Since we are auto-provisiong our Atlassian accounts from Microsoft Azure AD, we could easily map both addresses.

            We already map the work email, but what would happen if we start mapping also the personal email, given that right now it can be either

            • unkown to Atlassian: the personal email should be added as a secondary address to the existing account, but for what purposes would be used by Atlassian products?
            • already linked to an existing Atlassian account: I guess that things would get complicated in such cases

            Fabrizio La Rosa added a comment - Any news on this feature request, is Atlassian willing to put it in development roadmap? It is very important for us because we use Jira to manage service requests coming from our users and they could use either their work or personal email address. Since we are auto-provisiong our Atlassian accounts from Microsoft Azure AD, we could easily map both addresses. We already map the work email, but what would happen if we start mapping also the personal email, given that right now it can be either unkown to Atlassian: the personal email should be added as a secondary address to the existing account, but for what purposes would be used by Atlassian products? already linked to an existing Atlassian account: I guess that things would get complicated in such cases

            It's big vote from me. We use Jira in our company - and we use Active Directory (on-prem synced to Azure AD/Entra) as our identity base.

            Usually our users has username/upn, that does not corresponds with their email address - so for us there is a need to have mail aliases for login (sso).

            Anders von der Recke added a comment - It's big vote from me. We use Jira in our company - and we use Active Directory (on-prem synced to Azure AD/Entra) as our identity base. Usually our users has username/upn, that does not corresponds with their email address - so for us there is a need to have mail aliases for login (sso).

            +1  feeling the pain of this too. Lots of tickets raised by 'Anonymous User' because you cannot have new or legacy email addresses linked to the one Atlassian user as Aliases. 

            Michael Fechter added a comment - +1  feeling the pain of this too. Lots of tickets raised by 'Anonymous User' because you cannot have new or legacy email addresses linked to the one Atlassian user as Aliases. 

            i have an alias to my e-mail, this alias is in the company's directory, so, sometimes i've got added to a ticket using my alias, and i can't access it, because my alias doesn't have an Jira account...

            Sandro Magrinelli Vianna added a comment - i have an alias to my e-mail, this alias is in the company's directory, so, sometimes i've got added to a ticket using my alias, and i can't access it, because my alias doesn't have an Jira account...

            Just had to rename someone's account/email because they got married. Now I have two accounts because Atlassian doesn't allow multiple emails or the ability to 'combine' accounts. Now working with support to figure out a solution. This would save time for not only the customer, but Atlassian support as well. 

            Dusty Brossart added a comment - Just had to rename someone's account/email because they got married. Now I have two accounts because Atlassian doesn't allow multiple emails or the ability to 'combine' accounts. Now working with support to figure out a solution. This would save time for not only the customer, but Atlassian support as well. 

            It gets even more complicated when you start using assets - users have profiles only associated with 1 domain, yet they create tickets under the other email domain and the approval workflow looks up the profile domain and can't find it so it fails until you manually change the reporter field to the correct domain. Really frustrating!!!

            Manager - Service Delivery added a comment - It gets even more complicated when you start using assets - users have profiles only associated with 1 domain, yet they create tickets under the other email domain and the approval workflow looks up the profile domain and can't find it so it fails until you manually change the reporter field to the correct domain. Really frustrating!!!

            It is mindboggling that this issue has been open for nearly 7 years. My organization has grown by way of acquisition, and as such there are, and always will be, several email domains in use. Some users have 3, or even 4, separate Atlassian accounts, for example because they login to their account with our primary domain, but their email sends from a different domain, so if they are to email a request into a JSM project for example, it is submitted from their email alias and they cannot see their request upon logging in, as their Atlassian account is using a different email address from the one which they used to send in their email request.

            I see several comments along this vein. I see several other extremely valid use cases for this as well. My organization cannot scale with JSM if this remains unresolved.

            No work logged, no action on this ticket in years, except linking similar issues and changing the internal assignee. Been watching it for over a year and the only action that comes through is other folks commenting in frustration every couple of weeks. What's up? 

            Chad Klinefelter added a comment - It is mindboggling that this issue has been open for nearly 7 years. My organization has grown by way of acquisition, and as such there are, and always will be, several email domains in use. Some users have 3, or even 4, separate Atlassian accounts, for example because they login to their account with our primary domain, but their email sends from a different domain, so if they are to email a request into a JSM project for example, it is submitted from their email alias and they cannot see their request upon logging in, as their Atlassian account is using a different email address from the one which they used to send in their email request. I see several comments along this vein. I see several other extremely valid use cases for this as well. My organization cannot scale with JSM if this remains unresolved. No work logged, no action on this ticket in years, except linking similar issues and changing the internal assignee. Been watching it for over a year and the only action that comes through is other folks commenting in frustration every couple of weeks. What's up? 

            This has been driving me nuts for years. I consult with companies, so I have my own Atlassian account, but it's not uncommon for me to have an identity with the client as well, so then I end up with multiple email addresses associated with "me" and there will be situations like I get CC'd on a support ticket on my client email, but when I click the link, I can't view it, because Service Desk doesn't think my Atlassian account has access to the support ticket.

            If I could identify to Atlassian cloud that my client email id is just one more email address associated with my Atlassian account, that would significantly reduce this pain. And while my situation isn't everyone's, it's also not that uncommon.

            Geoffrey Wiseman added a comment - This has been driving me nuts for years. I consult with companies, so I have my own Atlassian account, but it's not uncommon for me to have an identity with the client as well, so then I end up with multiple email addresses associated with "me" and there will be situations like I get CC'd on a support ticket on my client email, but when I click the link, I can't view it, because Service Desk doesn't think my Atlassian account has access to the support ticket. If I could identify to Atlassian cloud that my client email id is just one more email address associated with my Atlassian account, that would significantly reduce this pain. And while my situation isn't everyone's, it's also not that uncommon.

            It would be nice if this can be added. We currently receive defender alerts from different customers, but since they can be send to only one address some alerts can not receive a label and therefore not be redirected to the corresponding queue. and from the info in the  ticket it is sometimes not possible to relate the ticket to the correct customers.
            having to ability to specify multiple email addresses would solve this issue. (Zendesk has this possibility but we want to move to jira)

            Stefan Voogt added a comment - It would be nice if this can be added. We currently receive defender alerts from different customers, but since they can be send to only one address some alerts can not receive a label and therefore not be redirected to the corresponding queue. and from the info in the  ticket it is sometimes not possible to relate the ticket to the correct customers. having to ability to specify multiple email addresses would solve this issue. (Zendesk has this possibility but we want to move to jira)

            We want our customers to get the default notifications from Jira currently they are not getting it because email address configured in Jira is a guest login id and its not there real email id its using AZURE for the same if its allowed to have secondary email address we can add there real email id and maybe they can get default notifications from Jira 

            Sanjivani Wayal added a comment - We want our customers to get the default notifications from Jira currently they are not getting it because email address configured in Jira is a guest login id and its not there real email id its using AZURE for the same if its allowed to have secondary email address we can add there real email id and maybe they can get default notifications from Jira 

            We need this as well.

            Brent Vierling added a comment - We need this as well.

            Adel H added a comment -

            In case this hasn't been added already, in our case with an SSO login (Microsoft) we use a different email address for login compared to our primary email address.

            eg ja@web.com and jira.atlassian@web.com  

            It is a shame that we are getting duplicate user entries because of this setup

            Adel H added a comment - In case this hasn't been added already, in our case with an SSO login (Microsoft) we use a different email address for login compared to our primary email address. eg ja@web.com and jira.atlassian@web.com   It is a shame that we are getting duplicate user entries because of this setup

            we are really interested

            Marco Rosati added a comment - we are really interested

            Sad to say, but my company and I have set sail 🚢 for GitHub, as we have been wanting this and a few other issues resolved (sadly they have not been for many years). Sadly, all the rum has gone 🍺 in the time we have been waiting.

            Andrew Brunker added a comment - Sad to say, but my company and I have set sail 🚢 for GitHub, as we have been wanting this and a few other issues resolved (sadly they have not been for many years). Sadly, all the rum has gone 🍺 in the time we have been waiting.

            Our employees have 2 emails. They log tickets with both emails.

            They login to the portal with one email but don't see all of their tickets.

            How can we fix it so they see all tickets from both emails?

            Thanks

            Wendy

            Wendy Thorneloe added a comment - Our employees have 2 emails. They log tickets with both emails. They login to the portal with one email but don't see all of their tickets. How can we fix it so they see all tickets from both emails? Thanks Wendy

            Alwin added a comment - - edited

            We just migrated from Jira Server to Jira Cloud.

            Some of our employees have switched emails since we started using Jira Server, and with our old LDAP integration it was no problem to just have them exist in Jira Server with multiple emails.

            However, when migrating to Jira Cloud we also switched IDP (Google Workspace), and for many stories the Reporter field is now linked to an inexistent user. The Reporter field can't be updated, so now we're stuck with broken links to the reporters of those issues, whom in many cases are stakeholders, and will not automatically updated about changes. Being able to just link multiple email addresses to users would solve this.

            I think it's bad product management to park this under GATHERING INTEREST as if it were just another feature request. It's a crippling omission for many of us who were all but forced to migrate from Jira Server to Jira Cloud, because Atlassian decided to drop support for their (non-enterprise) on-premise products. This is not something that should be prioritised based on number of requests alone.

            As more people are going to finally bite the bullet and migrate from Server to Cloud, you're going to see many more people coming in and complain about this oversight.

            Alwin added a comment - - edited We just migrated from Jira Server to Jira Cloud. Some of our employees have switched emails since we started using Jira Server, and with our old LDAP integration it was no problem to just have them exist in Jira Server with multiple emails. However, when migrating to Jira Cloud we also switched IDP (Google Workspace), and for many stories the Reporter field is now linked to an inexistent user. The Reporter field can't be updated, so now we're stuck with broken links to the reporters of those issues, whom in many cases are stakeholders, and will not automatically updated about changes. Being able to just link multiple email addresses to users would solve this. I think it's bad product management to park this under GATHERING INTEREST as if it were just another feature request. It's a crippling omission for many of us who were all but forced to migrate from Jira Server to Jira Cloud, because Atlassian decided to drop support for their (non-enterprise) on-premise products. This is not something that should be prioritised based on number of requests alone. As more people are going to finally bite the bullet and migrate from Server to Cloud, you're going to see many more people coming in and complain about this oversight.

            We went through a rebranding however had not changed our UPN (too many systems to migrate) so there is lots of user and customer confusion on how to get into our portal which domain to use etc. It would be very useful if both domains could access the single Atlassian account. 

            Manager - Service Delivery added a comment - We went through a rebranding however had not changed our UPN (too many systems to migrate) so there is lots of user and customer confusion on how to get into our portal which domain to use etc. It would be very useful if both domains could access the single Atlassian account. 

            This impacts employees who may need to combine Atlassian University coursework and certifications. Examples:

            • Employees changing companies.
            • Students who completed Atlassian certs and get hired.

            A company who does this well is Salesforce. They let Trailhead users associate a personal email account to an organizational account so that any Trailhead progress belongs to the user. 

            Oto Tabares added a comment - This impacts employees who may need to combine Atlassian University coursework and certifications. Examples: Employees changing companies. Students who completed Atlassian certs and get hired. A company who does this well is Salesforce. They let Trailhead users associate a personal email account to an organizational account so that any Trailhead progress belongs to the user. 

            I am positively confused how this is has not been a feature for the last 10 years at LEAST. This creates major problems for any organization that has internal emails for authentication, but others for communication, like in our case.

             

            Please prioritize this, or give us a workaround idea, even if we have to develop it ourselves.

            Christopher Capito added a comment - I am positively confused how this is has not been a feature for the last 10 years at LEAST. This creates major problems for any organization that has internal emails for authentication, but others for communication, like in our case.   Please prioritize this, or give us a workaround idea, even if we have to develop it ourselves.

            We migrated from RT (which was opensource and free). In that ticket system, it was as easy as typing a customer's name and clicking "Merge". Every customer here has at least two email addresses and if one isn't working then they will create a ticket with the other one which creates a new account and grouping of issues. Absorbing Trello and Bitbucket accounts with different email addresses has compounded the issue. Please make this feature request a priority so that I can stop talking about the old ticket system.

            Chad Graham added a comment - We migrated from RT (which was opensource and free). In that ticket system, it was as easy as typing a customer's name and clicking "Merge". Every customer here has at least two email addresses and if one isn't working then they will create a ticket with the other one which creates a new account and grouping of issues. Absorbing Trello and Bitbucket accounts with different email addresses has compounded the issue. Please make this feature request a priority so that I can stop talking about the old ticket system.

            I just realized this is why email + portal use is so painful in our organization; either users cc'd on the ticket can't see their own tickets (because they have a different Atlassian account) or all of their variations get added as participants and then they get email replies to their own comments.

            Jeremy Schwartz added a comment - I just realized this is why email + portal use is so painful in our organization; either users cc'd on the ticket can't see their own tickets (because they have a different Atlassian account) or all of their variations get added as participants and then they get email replies to their own comments.

            We have a customer that is rebranding so they have a new email they want to transition to, but wants both to be accessible while they transitioning. Would be nice to have an alias or secondary email address.

            Mike Lippel added a comment - We have a customer that is rebranding so they have a new email they want to transition to, but wants both to be accessible while they transitioning. Would be nice to have an alias or secondary email address.

            +1 for this. We have an official naming convention for emails which is what our Atlassian accounts get tied to, but users may request "vanity" emails with nicknames or short-names if they wish for client and other communications. This creates a million problems for email-to-ticket and authentication which would all be solved if we could tie multiple addresses to a single Atlassian account.

            Haddon Fisher added a comment - +1 for this. We have an official naming convention for emails which is what our Atlassian accounts get tied to, but users may request "vanity" emails with nicknames or short-names if they wish for client and other communications. This creates a million problems for email-to-ticket and authentication which would all be solved if we could tie multiple addresses to a single Atlassian account.

            Really! This is an active bug in 2022? I don't want to have multiple Atlassian accounts. Just the one, with my different emails (personal, work, etc.)

            Deleted Account (Inactive) added a comment - Really! This is an active bug in 2022? I don't want to have multiple Atlassian accounts. Just the one, with my different emails (personal, work, etc.)

            Tal Sofer added a comment -

            I got an invite to Bitbucket to one email, while my account is connected to another email. This limitation is blocking me from accepting the invite

            Tal Sofer added a comment - I got an invite to Bitbucket to one email, while my account is connected to another email. This limitation is blocking me from accepting the invite

            This feature is also required for email-support within Jira Service Management to not create duplicate Atlassian accounts for users with multiple send-from addresses.

            (ie. if aliases can be associated with an existing user for the emails they might send from, then it solves this problem).

            Anthony Kroeker added a comment - This feature is also required for email-support within Jira Service Management to not create duplicate Atlassian accounts for users with multiple send-from addresses. (ie. if aliases can be associated with an existing user for the emails they might send from, then it solves this problem).

            Dave Liao added a comment -

            💬 How is everyone working around the fact that we can't yet associate multiple emails to a single Atlassian account?

            I started a discussion on Atlassian Community, if anyone wants to share: https://community.atlassian.com/t5/Enterprise-articles/How-do-you-merge-different-companies-into-one-Marriages-in-Cloud/ba-p/2166315

            Dave Liao added a comment - 💬 How is everyone working around the fact that we can't yet associate multiple emails to a single Atlassian account? I started a discussion on Atlassian Community, if anyone wants to share: https://community.atlassian.com/t5/Enterprise-articles/How-do-you-merge-different-companies-into-one-Marriages-in-Cloud/ba-p/2166315

            Dave Liao added a comment -

            Dave Liao added a comment - I appreciate this user's take on the logic for how email aliasing would work: https://jira.atlassian.com/browse/ID-240?focusedCommentId=3180293&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-3180293

            We appreciate it too. Just do it, please

            Vladimír Bárta added a comment - We appreciate it too. Just do it, please

            fishern added a comment -

            +1 this is highly needed. Hopeful that there is something coming to allow this or integration to other systems to help. 

            fishern added a comment - +1 this is highly needed. Hopeful that there is something coming to allow this or integration to other systems to help. 

            Come on Atlassian, at this point you might as well just move this to Not Being Considered.  This issue has been open for years in many different forms, has hundreds of upvotes, and has comments littered with words like "urgent", "critical", "must have", "blocker", etc.  If you're still in the gathering interest phase, I can only assume you don't actually want to fix this.

            Josh Allanson added a comment - Come on Atlassian, at this point you might as well just move this to Not Being Considered.  This issue has been open for years in many different forms, has hundreds of upvotes, and has comments littered with words like "urgent", "critical", "must have", "blocker", etc.  If you're still in the gathering interest phase, I can only assume you don't actually want to fix this.

            This would be an amazing feature that is handled already in a wide variety of other applications. Would like to see this implemented asap, as it could be perceived that Atlassian is lagging behind the competition. 

            Andrew Brunker added a comment - This would be an amazing feature that is handled already in a wide variety of other applications. Would like to see this implemented asap, as it could be perceived that Atlassian is lagging behind the competition. 

            Working with multiple organizations and in turn, Jira accounts is a major pain point. Would love to see some movement on this issue. 

            Dylan Fontaine added a comment - Working with multiple organizations and in turn, Jira accounts is a major pain point. Would love to see some movement on this issue. 

            jan2000 added a comment -

            This would be an awesome feature. Thank you!

            jan2000 added a comment - This would be an awesome feature. Thank you!

            In our case - we have a slightly different problem. All of our users have logins/SSO with google and with microsoft that are identified as: userid@systemdomain.edu

            However, that isn't their primary email address. With 'Continue with Microsoft' option for login, they do get their actual email email (userid@localcampus.edu) – but if they use 'Continue with Google' for example, they get the wrong account - so it doesn't match up.

             

            I'd really like BOTH emails to be associated with the same user account so that if they send an email reply to a Jira email, it is properly handled, and so that it just works with either login mechanism.

            Nathan Neulinger added a comment - In our case - we have a slightly different problem. All of our users have logins/SSO with google and with microsoft that are identified as: userid@systemdomain.edu However, that isn't their primary email address. With 'Continue with Microsoft' option for login, they do get their actual email email (userid@localcampus.edu) – but if they use 'Continue with Google' for example, they get the wrong account - so it doesn't match up.   I'd really like BOTH emails to be associated with the same user account so that if they send an email reply to a Jira email, it is properly handled, and so that it just works with either login mechanism.

            Jon Az added a comment -

            Suggested workaround?

            Every user on our domain has an alias like `jdoe@acme.org` and a canonical address like `john.doe@acme.org`. If the user creates an account with `jdoe@acme.org` how do I associate that user with their canonical address so they can log in with SSO? Do I change their email address to the canonical one and bulk move the issues from their old identity to their new one? Are there tools for doing that in bulk? I'd hope that a procedure like that would be scriptable based on an export from our directory.

            Understand that you're still gathering interest, but would be great if you could publish a recommended workaround. Thanks in advance.

            Jon Az added a comment - Suggested workaround? Every user on our domain has an alias like `jdoe@acme.org` and a canonical address like `john.doe@acme.org`. If the user creates an account with `jdoe@acme.org` how do I associate that user with their canonical address so they can log in with SSO? Do I change their email address to the canonical one and bulk move the issues from their old identity to their new one? Are there tools for doing that in bulk? I'd hope that a procedure like that would be scriptable based on an export from our directory. Understand that you're still gathering interest, but would be great if you could publish a recommended workaround. Thanks in advance.

            Adam Bell added a comment -

            +1 from me.  We have a lot of reps that change names and receive a new email address.  We aren't going to change each rep's SSO just for Jira since all other systems can be integrated

            Adam Bell added a comment - +1 from me.  We have a lot of reps that change names and receive a new email address.  We aren't going to change each rep's SSO just for Jira since all other systems can be integrated

            Stepan added a comment -

            It is a great complication especially when SSO login we use is different from the internal customers = employees emails, which is an alias for SSO login. The whole Portal for ITSM is unusable, because employees need to login with a "second account". Does anyone have a solution for this situation please?!?

            Stepan added a comment - It is a great complication especially when SSO login we use is different from the internal customers = employees emails , which is an alias for SSO login. The whole Portal for ITSM is unusable, because employees need to login with a "second account". Does anyone have a solution for this situation please?!?

            Will this ever happen? Since this issue is from 2017.

            I really hope this get pushed through. Nobody likes to make multiple Trello accounts for work or use a private Trello account for work.

            Remzi Cavdar added a comment - Will this ever happen? Since this issue is from 2017. I really hope this get pushed through. Nobody likes to make multiple Trello accounts for work or use a private Trello account for work.

            +1

            Nick Hrabak added a comment - +1

            Alex Daley added a comment -

            +1 This feature is also useful for handling issue creation via email, where a user might might send email from multiple boxes and we want to consolidate all of that to properly identify their Jira account when assigning them as Reporter or Watcher. 

            Alex Daley added a comment - +1 This feature is also useful for handling issue creation via email, where a user might might send email from multiple boxes and we want to consolidate all of that to properly identify their Jira account when assigning them as Reporter or Watcher. 

            This has been a request on the table now by hundreds of users for half a decade now, is there any light coming from Atlassian?

            It is the one and only roadblock preventing us from moving to Jira Service Desk from Zendesk.

            Pete Peric added a comment - This has been a request on the table now by hundreds of users for half a decade now, is there any light coming from Atlassian? It is the one and only roadblock preventing us from moving to Jira Service Desk from Zendesk.

            +1

            (Psst! The voting is open, it's possible to upvote rather than just comment).

            Piotr Janik added a comment - (Psst! The voting is open, it's possible to upvote rather than just comment).

            +1

            Kjetil Furuly added a comment - +1

            +1

            olegshilov added a comment -

            +1

            olegshilov added a comment - +1

            Kevin Holt added a comment -

            +1

            Kevin Holt added a comment - +1

            Bill Sklar added a comment -

            This would be amazing. We have some developers with old and new addresses that are different between Slack and Jira.

            Bill Sklar added a comment - This would be amazing. We have some developers with old and new addresses that are different between Slack and Jira.

            This would be extremely helpful for resolving pain points when migrating domains.

            Ali Ebrahim added a comment - This would be extremely helpful for resolving pain points when migrating domains.

            Dave Liao added a comment -

            Ah, this is the ticket I meant to write many moons ago.

            This should be a lot easier to do than ID-240. 😂

            Dave Liao added a comment - Ah, this is the ticket I meant to write many moons ago. This should be a lot easier to do than ID-240 . 😂

            +1. I'm definitely backing this as we have people sometimes writing from one domain and then from the other...

            Tobias Soltermann added a comment - +1. I'm definitely backing this as we have people sometimes writing from one domain and then from the other...

            +1

            I can understand the complexity of implementing something like this and making it backwards compatible. However, since the goal is to have all systems interconnected (slack, salesforce, etc) people may have different email addresses in each system (company domain name changes over time) AND we're paying per user in jira, this makes it a PITA to manage users and integrations.

            Jonathan Bishop added a comment - I can understand the complexity of implementing something like this and making it backwards compatible. However, since the goal is to have all systems interconnected (slack, salesforce, etc) people may have different email addresses in each system (company domain name changes over time) AND we're paying per user in jira, this makes it a PITA to manage users and integrations.

            cemerson added a comment -

            I've migrated all my repositories and that of the organisation I work for over to github as a result of the refusal to look at this.

            cemerson added a comment - I've migrated all my repositories and that of the organisation I work for over to github as a result of the refusal to look at this.

            Our Jira customers are all internal to the company and everyone uses the same Azure AD with SSO to Jira. This issue is very painful for us because some of those users have different primary email addresses and it confuses Jira. They don't get Jira emails.

            Sean Dippold added a comment - Our Jira customers are all internal to the company and everyone uses the same Azure AD with SSO to Jira. This issue is very painful for us because some of those users have different primary email addresses and it confuses Jira. They don't get Jira emails.

            This would be extremely helpful for us - we provide email addresses to our users, in first initial.lastname format, IE, mharford@uwaterloo.ca. But we also allow users to have a friendly email alias: matt.harford@uwaterloo.ca. This means, users submit a ticket through the portal using the short form (because that's how they sign in), and if they go to reply via email, it comes from their alias. Without being able to link multiple email addresses to a single user, we get duplicate tickets.

            Any progress on this would be greatly appreciated. 

            Matt Harford added a comment - This would be extremely helpful for us - we provide email addresses to our users, in first initial.lastname format, IE, mharford@uwaterloo.ca.  But we also allow users to have a friendly email alias: matt.harford@uwaterloo.ca.  This means, users submit a ticket through the portal using the short form (because that's how they sign in), and if they go to reply via email, it comes from their alias. Without being able to link multiple email addresses to a single user, we get duplicate tickets. Any progress on this would be greatly appreciated. 

            @Patrik.Nyberg - Maybe I can help you here with a workaround to provision azuread b2b guest user with a valid domain into jira. I wrote the guide in my blog: https://patchfox.de/en/best-practise-how-to-provision-b2b-user-in-azuread-enterprise-applications/

            If you have further questions, you can ask me.

            Mario Schuetzle added a comment - @Patrik.Nyberg - Maybe I can help you here with a workaround to provision azuread b2b guest user with a valid domain into jira. I wrote the guide in my blog: https://patchfox.de/en/best-practise-how-to-provision-b2b-user-in-azuread-enterprise-applications/ If you have further questions, you can ask me.

            We urgently need this feature. 

            Just wondering if anyone has used a plugin or script to get around this issue?

            Bronagh Quinn added a comment - We urgently need this feature.  Just wondering if anyone has used a plugin or script to get around this issue?

            We also have an urgent need for this. We are using SAML for SSO, external users/contractors that need access to our Jira needs to have an account from our internal IdP to get access. But they will not get an email address from us. So they will not have the possibility to get notifications if they can't add an additional email address. 

            Patrik.Nyberg added a comment - We also have an urgent need for this. We are using SAML for SSO, external users/contractors that need access to our Jira needs to have an account from our internal IdP to get access. But they will not get an email address from us. So they will not have the possibility to get notifications if they can't add an additional email address. 

            hakobpogh added a comment -

            Hey guys. I just really want to mention that we do need that feature in our team too. I'm using Github for that only reason. (Also, multiline comments). That would be nice to have that feature in Jira too.

            hakobpogh added a comment - Hey guys. I just really want to mention that we do need that feature in our team too. I'm using Github for that only reason. (Also, multiline comments). That would be nice to have that feature in Jira too.

            Joao Zampa added a comment -

            Hy guys,

            Sorry but this seems to be a basic feature to have.
            This is causing a huge issue for us.
            Users on our organization have the default domain that provides them access to systems but they usually communicate via email using their local Alias.
            As we have operations all over the globe, it makes sense to them to send emails using the local brand. 
            On Jira, their account is created with the default domain but when they need to interact with the ticket, their email address is different than the one that they opened the ticket.
            So if they create a ticket using a form on the portal, the reporter will be the default domain but the other emails sent during the ticket interaction won't make it to the ticket as they will be using the local brand domain.
            Any idea when this is going to be added to the Road map?

            Joao Zampa added a comment - Hy guys, Sorry but this seems to be a basic feature to have. This is causing a huge issue for us. Users on our organization have the default domain that provides them access to systems but they usually communicate via email using their local Alias. As we have operations all over the globe, it makes sense to them to send emails using the local brand.  On Jira, their account is created with the default domain but when they need to interact with the ticket, their email address is different than the one that they opened the ticket. So if they create a ticket using a form on the portal, the reporter will be the default domain but the other emails sent during the ticket interaction won't make it to the ticket as they will be using the local brand domain. Any idea when this is going to be added to the Road map?

            kl3ryk added a comment -

            +1

            kl3ryk added a comment - +1

            Paul Sherry added a comment - - edited

            Would be useful in the scenario I have where we are working on a migration to Cloud from Datacentre, and current users have their own separate company email for their ID's. With the migration we are integrating into the company Azure / O365 with SSO and MFA to better control user access and to meet security control and auditing requirements around access to the data stored in the Atlassian tools, so each user will be provisioned with the organisation ID (in [user]@[companydomain] format), but we were not planning to setup an email account for each external user. This would/may require another MS license which we'd of course prefer not to have to purchase just for notifications to Atlassian product notifications to "external" users.     

            Paul Sherry added a comment - - edited Would be useful in the scenario I have where we are working on a migration to Cloud from Datacentre, and current users have their own separate company email for their ID's. With the migration we are integrating into the company Azure / O365 with SSO and MFA to better control user access and to meet security control and auditing requirements around access to the data stored in the Atlassian tools, so each user will be provisioned with the organisation ID (in [user] @ [companydomain] format), but we were not planning to setup an email account for each external user. This would/may require another MS license which we'd of course prefer not to have to purchase just for notifications to Atlassian product notifications to "external" users.     

            Useful feature in particular working cross teams.

            Georg Jezersek added a comment - Useful feature in particular working cross teams.

            This is also a critical feature for my company after we experienced a merger. Repy to comment by email no longer works since the originating domain of our email addresses changed.

            Jeremy Agostino added a comment - This is also a critical feature for my company after we experienced a merger. Repy to comment by email no longer works since the originating domain of our email addresses changed.

            It is a crucial feature as you've already forced me to create 4th redundant account on your system just because of some silly rules.

            Andrzej Herok [TSH] added a comment - It is a crucial feature as you've already forced me to create 4th redundant account on your system just because of some silly rules.

            Daniel Liu added a comment - - edited

            Very need this feature because we are doing outsource work and sometimes our clients will assign us an email address of their company for months, for temp use . and clients always changing.

            Daniel Liu added a comment - - edited Very need this feature because we are doing outsource work and sometimes our clients will assign us an email address of their company for months, for temp use . and clients always changing.

            This really is a "must have" feature.  After a company merger, all of our user's primary account email addresses don't match their default send-as address.  Therefore, the majority of the emails coming in aren't matched to a known user.  Even our sub-par IT helpdesk platform handles multiple email accounts per user and offers the ability to merge users when duplicates are discovered.

            Brandon Fish added a comment - This really is a "must have" feature.  After a company merger, all of our user's primary account email addresses don't match their default send-as address.  Therefore, the majority of the emails coming in aren't matched to a known user.  Even our sub-par IT helpdesk platform handles multiple email accounts per user and offers the ability to merge users when duplicates are discovered.

            This is a huge issue for us. We're using SSO with Jira/Confluence Cloud, which means we need a verified domain. One of the other divisions of our parent company had already set up a Jira instance with our main domain, so we needed to get email aliases for a separate domain for all users in our division/instance. This is fine, except when those users are also internal Service Desk customers and attempt to reply to a comment on a ticket via email. Because emails come from our main domain, not our verified domain, sometimes it creates new tickets, and other times their comments just vanish into the cloud because they don't have permissions to create tickets using the main domain.

            Esther Strom [ACP-JA] added a comment - This is a huge issue for us. We're using SSO with Jira/Confluence Cloud, which means we need a verified domain. One of the other divisions of our parent company had already set up a Jira instance with our main domain, so we needed to get email aliases for a separate domain for all users in our division/instance. This is fine, except when those users are also internal Service Desk customers and attempt to reply to a comment on a ticket via email. Because emails come from our main domain, not our verified domain, sometimes it creates new tickets, and other times their comments just vanish into the cloud because they don't have permissions to create tickets using the main domain.

            Pete Peric added a comment - - edited

            I agree with 489983f66fb0 as I am in the same boat. Because of this problem, we have chosen NOT to switch over to JIRA Service Desk and simply stay with Zendesk Support until Atlassian resolves this problem. Having multiple email addresses and accounts for customers is not only an administrative nightmare and counter-productive, but extremely confusing and cumbersome for the end users, especially end users who are not tech-savvy. 

             
            I would like to inform Atlassian that our team was excited to review and switch to JIRA Service Desk as preliminary testing met all our requirements for a multi-department, multi-tenancy ticketing system. However, we ran into one major roadblock for us which required us to not proceed. One of our requirements is a ticketing system which allows multiple email addresses and phone numbers for a customer end-user. Especially since we authenticate with G Suite but our users have a different domain alias after our company changed names.

            Pete Peric added a comment - - edited I agree with  489983f66fb0  as I am in the same boat. Because of this problem, we have chosen NOT to switch over to JIRA Service Desk and simply stay with Zendesk Support until Atlassian resolves this problem. Having multiple email addresses and accounts for customers is not only an administrative nightmare and counter-productive, but extremely confusing and cumbersome for the end users, especially end users who are not tech-savvy.    I would like to inform Atlassian that our team was excited to review and switch to JIRA Service Desk as preliminary testing met all our requirements for a multi-department, multi-tenancy ticketing system. However, we ran into one major roadblock for us which required us to not proceed. One of our requirements is a ticketing system which allows multiple email addresses and phone numbers for a customer end-user. Especially since we authenticate with G Suite but our users have a different domain alias after our company changed names.

            Kevin Kee added a comment -

            Fewer than 30 minutes after JRACLOUD-3160 was closed to move the discussion of multiple email address support to this issue, I dropped everything I was doing so I could upvoted, comment on, and follow.

            Every user on my instance of JSD for uses aliases, and no one uses their primary address for sending. This means that every ticket created gets duplicated the moment a user replies to one of the JSD-generated emails. Email integration is impossible.

            We really, really need this feature.

            Kevin Kee added a comment - Fewer than 30 minutes after JRACLOUD-3160 was closed to move the discussion of multiple email address support to this issue, I dropped everything I was doing so I could upvoted, comment on, and follow. Every user on my instance of JSD for uses aliases, and no one uses their primary address for sending. This means that every ticket created gets duplicated the moment a user replies to one of the JSD-generated emails. Email integration is impossible. We really, really need this feature.

            Pete Peric added a comment - - edited

            Alias support is needed for us. We want to leave Zendesk and switch to Jira Service Desk, but not being able to support email aliases for our "customers" (internal employees) is making it a blocker.

            Main reason why we need email alias support is so end users can login to the portal with their G Suite account. However, after our company changed names they still login with their old email address, but have all outgoing email come from their domain alias address.

            Pete Peric added a comment - - edited Alias support is needed for us. We want to leave Zendesk and switch to Jira Service Desk, but not being able to support email aliases for our "customers" (internal employees) is making it a blocker. Main reason why we need email alias support is so end users can login to the portal with their G Suite account. However, after our company changed names they still login with their old email address, but have all outgoing email come from their domain alias address.

            It's absolutely bonkers, all competitors have this... I'm going to recommend ending the use of Bitbucket from now on every time I see it.

            Matti Järvinen added a comment - It's absolutely bonkers, all competitors have this... I'm going to recommend ending the use of Bitbucket from now on every time I see it.

            robertmeta added a comment -

            This issue is annoying enough in regards to Bitbucket to make me prefer using github over it for dealing with clients.  There is no reason this shouldn't be fixed. 

            robertmeta added a comment - This issue is annoying enough in regards to Bitbucket to make me prefer using github over it for dealing with clients.  There is no reason this shouldn't be fixed. 

            Bump

            Anton Ukhanev added a comment - Bump

            iMartyn added a comment -

            Come on Atlassian, this is nearly a year old and has 500+ upvotes in it's previous incarnation and you still need to "verify if this issue exists".

            I don't expect that this issue will be listened to any more than the previous, but I'm going to keep banging this drum.

            iMartyn added a comment - Come on Atlassian, this is nearly a year old and has 500+ upvotes in it's previous incarnation and you still need to "verify if this issue exists". I don't expect that this issue will be listened to any more than the previous, but I'm going to keep banging this drum.

              ef0fd77f42fd Freddie Xavier (Inactive)
              awilkes Alastair Wilkes
              Votes:
              981 Vote for this issue
              Watchers:
              498 Start watching this issue

                Created:
                Updated: