How to configure 'Reply to Customer' notifications to go to all Request Participants EXCEPT inbound

[Andy Maslen]

We are using Jira Service Desk (cloud - latest interface) having migrated from Freshdesk.

We service multiple organisations and within each organisation there are a number of supervisors that have access to all issues. We achieve this by an automation rule that adds them as Request Particpants for any issue in their organisation.

Our primary inbound channel is email.

When an issue comes in the sender is the reporter and any cc's become Request participants (they may, or may not, be included in the automation).

The problem now comes that the inbound support email address then also gets added as an RP.

For that reason the email templates have to be configured to only send to the reporter - when we send to all involved a notification comes back into our support email which then loops with notifications.

Our clients want to be notified of updates for tickets they did not raise but even the @ mention does not work in this configuration.

I have been working with ai and Rovo and have been attempting multiple approaches but they all end in failure with 'this is a known limitation of Jira'.

Surely something so fundamental as being able to notify a supervisor of a ticket update for their employee should not be so difficult?

Any help or guidance very much appreciated.

[Trudy Claspill]

Hello @Andy Maslen 

Welcome to the Atlassian community.

It seems like the solution is to remove the inbound support email address from Request Participants so that outgoing emails don't get routed back as incoming emails.

How is the inbound support email address getting added to Request Participants for the issue? I don't believe that is default functionality, unless that email is getting included in the CC of the original email.

[Andy Maslen]

That's a great question. It is behaving like it is the default behavour so interesting to know its not.

When we originally configured the system I had the following setting for Customer Sharing

search those within their organization only.

In this configuration if a CC was added to the email that was not already a customer it was ignored. As we wanted to capture CC's in the Issue (so we could respond to all involved) I changed the setting to:

search those within their organization, or enter the email address of customers within their space.

This seemed to have the desired result (initially) as the CC's were added.  However this was when we noticed that the inbound email we are using was also added...however they are not CC'd on the email.

One point of note. The email address itself is a microsoft distribution list. Could this be causing the unexpected behaviour of the To: being added as a cc?

I was originally hoping that the @ mention would work for external customers but it seems, even though when we @ we see a list of all request participants and can select them, this functionality does not send an external notification - is that expected? If I can configure that to work it will also be a way to resolve this particular problem.

Thanks for any assistance.

[Andy Maslen]

@Trudy Claspill I may have an explanation for the adding of the inbound mail address. As mentioned previously we are using a distribution list.  Because such a list could not be added as an external email address we are using a transport rule to forward the email to the support@xxxxxx.atlassian.net default mail handler. I suspect this is what is causing the inbound email to appear as a request participant.

It is not possible to convert a dist list to a mailbox, hence why we are in this bind. Right now changing the method of receiving the emails is not something can can easily be changed - At least now I understand why we are getting unexpected behaviour! Any thoughts on how to get myself out of this conundrum?

[Trudy Claspill]

Sounds like you have done good research on this issue.

Disclaimer: customization of email handling/transport rules is not an area of expertise for me.

Do I understand correctly that the original email is going to a distribution list that does not include the JSM email account, and that you then forward that email to the JSM email account?

What is the email handler account set up in the JSM project? What I have seen in my own instance is that, but default, the account is named <projectKey>@<siteURL>, but you said your "default mail handler" is support@xxxxx.atlassian.net. (I realize the xxxx is a placeholder.) The point of my question is to ask if "support@xxxxx.atlassian.net" is the email address set in the JSM project as the "Connected email account".

What problem are you trying to solve by having the initial email sent to a distribution list? Why not have it sent directly to the Connected Email Account for the JSM project?

Are the members of the distribution list subsequently added to the created issues as Request Participants or Watchers?

Have you considered or already tried adding the JSM email address to the distribution list rather than forwarding the email to it?

Your last paragraph:

I was originally hoping that the @ mention would work for external customers but it seems, even though when we @ we see a list of all request participants and can select them, this functionality does not send an external notification - is that expected? If I can configure that to work it will also be a way to resolve this particular problem.

Can you walk me through this scenario - what are you doing, what do you hope to see happen (who do you hope gets notifications), and what actually happens?

In what field are you mentioning the Request Participants? If it is a comment, is that a public comment or an internal comment?

Notifications to Request Participants should align with the Customer Notifications settings for the project. I have seen previously (but have not recently retested) that if a user is both a Request Participant and a Watcher then the Notifications may not get sent as expected.

[Andy Maslen]

Hi @Trudy Claspill many thanks for your detailed response.

Why use a distribution list?

This is a legacy from our previous support system.  The email address was setup as a distribution list 15 years ago and has been in use with all our clients for many years. We did not wish to add burden of email change to clients

Why not add the Atlassian email address to the distribution list

Its and external address so we cannot add to the microsoft distribution list 

The point of my question is to ask if "support@xxxxx.atlassian.net" is the email address set in the JSM project as the "Connected email account".

Yes this is the connected mail account (it was the default setup when system configured itself)

What problem are we trying to solve?

Be able to notify a portal user, that is not the reporter, when updating the issue with a Public Comment. For example user A reports an issue and user B (their supervisor) is CC'd. When responding to the issue we wish to notify user B that there is an update.  Important we do NOT want to do this for all RP's for all organizations (hence the complexity).  I am aware I could update the notification type to notify all 'Customers Involved' but this is not the desired outcome (too much noise for too many people).

I have found conflicting information regarding the '@' mention feature for portal customers in Public Comments but basically that would be what we are trying to achieve.