Now you can connect multiple support email addresses to your service project

[#1]

Hello Everyone,

I am excited to announce that we have started rolling out the ability to add multiple support email addresses in JSM project. Now you can add upto 10 email addresses in each project to collect email support queries. Each support email address can be assigned a request type, making it easier for you to route email requests.

What is it?

Your service project comes with a pre-configured Atlassian cloud email address that you can send to customers to start using right away. Any emails sent to this address will become issues in your service project.

You can configure your email channel to receive requests from email addresses other than the pre-configured email address. You can select whether to create a new Atlassian email address or add an existing external email address to receive requests from your customers. With the new improvements, a service project can now have up to 10 email addresses connected to it.

We have also improved the appearance of the ‘Email Requests’ page to make it easier for you to configure multiple support emails.

How does it work?

• Create a new Atlassian email address for receiving requests

To create a new Atlassian email address:

1. From your service project, select Project settings, and then Email requests.

2. Select Create Atlassian email.

3. Enter the email address of your choice. If you enter the value of the prefix as support, then your email address will be support@companyname.atlassian.net.

4. Select a suitable request type for the new Atlassian email address that you’re creating. Any requests created from this email address will be automatically assigned the selected request type.

5. Select Create.

The new email address will be added to the list of connected email accounts.

• Add an external email address for receiving requests

To add an external email address:

1. From your service project, select Project settings, and then Email requests.

2. Select Add external email.

   1. If you select Google as your email service provider, select Continue with Google and complete the authentication in the new tab.

   2. If you select Microsoft as your email service provider, select Continue with Microsoft and complete the authentication in the new tab.

   3. If you select Other as your email service provider, select Continue with Other. Enter details of your external email address and select Add.

3. If you’ve connected a Google or Microsoft email account, you can update the request type after the authentication is successful.

• View connected email accounts

To view connected email accounts for your service project:

1. From your service project, select Project settings, and then Email requests.

2. For each connected email account, you can view:

   • Email address: The complete email address

   • Request type: The request type assigned to an email address

   • Incoming logs: Detailed incoming email logs for an email address.

   • Last email received: When the last email was received from an email address

Choose a suitable request type for an email address

When a customer sends an email to a connected email address, a request is created and the request type linked to the email account is automatically assigned to the request.

It's important to choose a request type suitable for the email channel to ensure that all your email requests are created successfully. When connecting an email address, ensure that the request type you choose has only Summary and Description as the required fields. If additional required fields are added to a request type linked to an email address, requests will not be created from customer emails sent to that particular email address. 

We have started rolling this out and expect to be available to all customers by 24th June. Also, this functionality is currently available for Company Managed projects only.

If you have any questions or comments, let's discuss!

Best Regards,

Manpreet Singh

PM, Jira Service Management

[Daniel Sidler]

Great feature, thanks!

Will this also address the issue that, in a project where channel access is restricted to known customers, we can't auto-reply to the rest with an auto-generated message?

Currently, when a non-registered customer sends an email to support@companyname.atlassian.net (or to a connected M365 email account) their message is silently dropped. Even though the logs shows "Sorry, self-signup is disabled for this help center. You need to be invited first."

We want this log message to be replied to the original sender, so that they know the request is not processed. For various reason we can't allow self-registration but need a way to deal with external senders not yet set up as customer. Silently dropping might be an effective way to deal with spam, but it's also bad customer service. 

[Matthew Challenger]

Also agreed that this is a great feature with lots of room for extension!

Our use case is multi-language. It would be more seamless for us if we could easily set that all Customer Notifications in English use email A, while all Customer Notifications in French use email B. This would include requests made via the portal.

[Joerg]

This is almost perfect timing as we have a use case for this feature i.e. connect multiple Google addresses to a Service Desk each with their own request type.

Looking forward to using it starting June 24th or sooner in case it's released sooner on our instances.

[Natasja Eloff]

It would be great if the functionality exists where an added mailbox/connection can be set to deactivated or disabled.
This is required for testing.
Now you have to remove the connection and then add it again. 
Or maybe have the ability to deselect a request type to have the connection not create any requests.

[eb]

I CAN'T BELIEVE ! THIS EXIST ! no words : thaaaank you 

[Chris Riffey]

Any chance the limit could be higher than 10? 😎

[Josh]

This is a great improvement! It's great to see this sort of quality-of-life enhancement implemented.

[Kim-Stacey Kidder]

Doing the happy dance!! lol! 🎉

[David Petrík]

Nice, but it would be nice to be able to also specify the address by request type when sending (notifications), not just for receiving.

We are using Freshdesk for now and we are testing whether to switch to atlassian and this is an annoying thing. Yes we can have x projects for our multilingual support addresses, but who on earth is to figure it out.

Another blocking issue is that JSD can't put the communication history in the reply. It's funny to see big companies announcing AI creatures that will do what you want, but the common things you want can't be found.

[Luke Nunn]

I am hoping this will allow us to generate tickets from Office365Alerts@microsoft.com for user-reported email phishing. i.e. have MS Defender send these to a specific mailbox and connect that mailbox to the project with a ticket type specific to them. 

[Daniel Szewczyk]

This would be useful if there was no limitation to Summary and Description fields being only mandatory fields on the Request Type. I imagine that applying some default values for other mandatory fields for email request wouldn't be too problematic to develop.
Otherwise we have to have separate Request Types for email and web requests which makes the setup too complicated to mainain.

[Joanna Cox]

Hi there, Is this new JSM feature available under the Standard version or only Premium or Enterprise?

[Jack Brickey]

Awesome! This is a nice feature update.

[Karin Kennergren]

This is just SO GREAT! Any possibility to have the reply-to address aligned so it is coherent?