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

Question

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.

Andy Maslen · Answer

Hi @Trudy P 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.

Trudy P Claspill · Answer

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 @, 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 · Answer

@Trudy P 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?