Handling intake when users have multiple mail aliases

[Matt Harford]

I'm wondering if anyone has any experiencing managing users with multiple email addresses assigned? Each of our users has (or may have) a userid-based email, ie jmiller@uwaterloo.ca, but also, an alias, ie John.miller@uwaterloo.ca. 

This causes a problem for us because when people log into the portal, we use their userid@uwaterloo.ca - and so the ticket get's opened under jmiller@uwaterloo.ca

Then, when they reply to the email message to continue communication, it comes from John.miller@uwaterloo.ca, which ends up opening a new request. 

Is there any way to handle this automatically? I can't find any other mention of it, but we can't be the only organization that has this problem.

[Benjamin Paton · Accepted solution]

Hey Matt,

Currently this is not possible short of having multiple free customer accounts for a user.

It is something we are evaluating, and are keen to learn more about how this is impacting your organisation.

Would you mind voting and sharing your feedback here https://jira.atlassian.com/browse/ID-240

Thanks,

Ben.

[Matt Harford]

Thanks Ben, I will vote and share my feedback right away. Can you expand more on using multiple free customer accounts and how we could use this to eliminate the duplicate ticket problem?

Cheers,

Matt 

[Benjamin Paton]

Thanks for sharing your feedback.

For multiple accounts, it is not a great solution, but If you have customer accounts for each alias a user emails you with, and those accounts are a part of the same organisation, and automatic organisation sharing is enabled, you should be able to avoid duplicates.

But I can certainly appreciate this is a lot of administrative overhead.

[Matt Harford]

Thanks Ben,

We may end up doing this as this may be better than the alternative of constant duplicates. This is very helpful, thank you for sharing the above. Hopefully there is some action on ID-240 soon. 

-Matt 

[Matt Harford]

@Benjamin Paton So we tried to set this up recently - but there is the side effect of all tickets then being fully visible to all others within the "organization". Is there a way to configure this so organization sharing is enabled, but visibility into issues is not?

Thanks,

Matt

[Benjamin Paton]

Can you help me understand what sharing capability you would want, while denying visibility?

[Matt Harford]

Hi Ben, we are just trying to allow people to "update" requests from an alias email address without it creating a duplicate ticket. 

While what you suggested above does work, but it also allows everyone within the organization to have full visibility into every single ticket. 

If it's possible to allow organization sharing with just the ability to update the request, but not to see any ticket details, that would actually work perfectly for us.

Thanks, 

Matt

[Josh Mohan]

Hello @Matt Harford  and @Benjamin Paton  , would you mind letting me know where this 'automatic organization sharing' is located? I believe this will solve a similar issue in my organization, but I'm struggling to find it in the permissions list / settings.

[mararn1618 _secretbakery_io_]

Sorry Josh, I have no idea either.

[Matt Harford]

@Josh Mohan it's in the Global settings: https://yourname.atlassian.net/secure/admin/SDConfiguration.jspa

[Benjamin Paton]

Hey @Matt Harford, 

It might make more sense at this point to have a chat about your scenario. 

If you are open to it, please book a slot in my calendar. 

Cheers, 

Ben.

[Josh Mohan]

Thanks Ben! Put some time in your calendar later today.

[Michal Wendrowski]

We also have this issue and would very much appreciate a solution.

[mararn1618 _secretbakery_io_]

Hey @Michal Wendrowski , don't know if you have seen it – the app Duplicate AI will automatically display those falsely created new tickets and let you merge them with one click.

Disclaimer: I'm the app owner. 😉

[Garrett Pennell]

You are not the only organization that has this problem. It's a major annoyance for us as well. We try to explain to submitters that they should try to use the same email address from which they normally reply, but that is not something most users really have an awareness of. Plus, they have different aliases configured from different email clients.

My suggested solution is for there to be a feature in Jira Service Management that allows me to add alias email addresses to an end users' profile. That way when emails come in, JSM understands that they're from the same person. Or, better yet, connecting to Google Workspace could do that for me, maybe.

Thank you, Atlassian team, for your time and attention.

[mararn1618 _secretbakery_io_]

Hey @Matt Harford , I'm an app developer and actively working on this topic right now. Would you be interested in bouncing off some ideas and getting your hands on the early prototype?

Let me know, I'm always happy to share.

[Matt Harford]

Absolutely! Would love to participate in this!