How to use Project Automation to remove specific Request Participants based off of the email address

[German Rodriguez]

Hello,

I am trying to use Jira Project automation in Jira Service Desk Cloud to detect issues with specific Request Participants and remove that entry while preserving the other entries that might exist.

Situation:

We use Office 365 and Distribution Groups (DGs) and our users create issues by emailing the email address configured in Email requests, servicedesk@company.com (this is actually an alias/Contact for servicedesk@companyname.atlassian.net).

We have internal DGs for departments, such as Accounting with the email address Accounting@company.com. The Accounting DG has user1@company.com and user2@company.com in it.

When a user1 sends an email to servicedesk@company.com (to create a new issue) and they CC their department, accounting@company.com, to keep them in the loop of things, an issue in Jira will be created with user1@company.com as the Reporter and accounting@company.com as the Requested Participant. User2 will receive the direct message (outside of Jira) from User1 because they are in the Accounting DG, and if they Reply All to that email they will reply back to User1, servicedesk, and Accounting DG.

Because Jira is not aware of Distribution Groups it can't validate that User2 is in the Accounting DG to allow them to comment on the issue, so Jira just creates a new issue essentially forking/duplicating the issue. Sometimes with larger departments this is more troublesome.

Seeking a solution:

Ideally the solution would be for Exchange to expand the DG and replace the DG with the actual people in it, but I have not found a way to do that with an Exchange rule (also that's for another forum).

So, that's why I am looking into Jira to see if there is a possibility with Project automation.

I suspect that I will have to have an automation rule that will have to match all of the email addresses to our internal DGs. I realize that is a separate "thing" to maintain and I accept that.

I am thinking Pseudo-code version of the Automation rule goes something like this:

• When: Value changes for Request participants
  • For Create issue and Edit issue
• If Request participants contains any of:
  • my list of DG email addresses
• Then: Edit issue fields
  • Advanced:
    • This is where I am stuck. I was thinking something along the lines of using the custom field for Request Participants and trying to use the Smart Values in combination with the replace/remove function to remove the unwanted email addresses.

    • {
          "fields": {
              "customfield_10023": {
                  "emailAddress": {{issue.customfield_10023.emailAddress.remove("accounting@company.com")}}
              }
      
          }
      }

• And Add comment to issue
  • Comment to user explaining to not use Distribution Groups in emails to the service desk.

[Andreas Lärkfeldt]

Hi, its sadly not possible with "name" or "email" - but with "id" :)

I've written a guide on how to fix the original issue (mentioned on top):
https://community.atlassian.com/t5/Jira-Service-Management/Remove-quot-Request-Participants-quot-using-Automation-rule/qaq-p/460812#U1630417 

I hope that helps! :)

[Matías Averbuj]

I'm having a similar issue as we setup several email aliases to the primary customer email account on Service Desk and the alias gets correctly added as a Participant. But when a comment or status is done on a request it notifies the Participant (the alias of the Jira email account) and it begins to create requests in a loop. No idea how to solve for this yet. 

[German Rodriguez]

Hi Matías,

I edited my original post to reflect that I am also using an alias/Exchange Contact for our users to send emails to our Service Desk Project.

servicedesk@company.com is an alias/contact for servicedesk@companyname.atlassian.net

Our Jira issues also get created with the servicedesk@company.com email address as a Request Participant, but we are not noticing any email loops. Also, I don't remember configuring an option in Jira to prevent this. Hmmm......

In hindsight, I am beginning to suspect that it might have been a better idea to have Jira logging into a mailbox to fetch emails and turn those into issues, which is the option under the section Connect a custom email account.

Although that method still doesn't solve my original problem with distribution groups/lists.