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?