Jira Automation Email - Send 1 email to assignees on old tickets

[patman_y]

Hello Jira folks, 

I currently have the following setup: 

- Jira automation run on a daily basis at 8 AM
-- JQL: project = DEV AND status = Todo AND updated <= -2d ORDER BY updated ASC
--- Email to Assignee + Teamleader + Head of Department:
Subject:
Late ticket: {{issue.key}}

Body: 
Hello {{assignee.displayName}} 

Please look into this ticket urgently {{issue.key}} 


This is causing me issues as I am sending 1 email per issue, and it is spamming the team on a daily basis. 

Instead, what I'd love to see is: 
1 email per assignee to the correct Assignee + Teamleader + Head of Department 
-> Assignee/dev would have 1 email sent to him containing all of the tickets he's late for
--> Teamleader would have multiple devs under his scope, so he should receive multiple emails, but only 1 email per assignee/dev
---> Head of Department would have multiple Teamleaders (therefor multiple devs) under his scope, so he should receive multiple emails, but only 1 email per assignee/dev

Expected Subject: 
{{assignee.displayName}} - Late tickets

Body would be something like: 
Hello {{assignee.displayName}} 

You have a list of tickets that are unattended to: 
{{for loop of issues}}

 [{{issue.updated}}: {{issue.summary}} - {{issue.key}}]({{issue.url}})

{{/for loop of issues}}


Any advise on how to do that? 

[Bill Sheboy]

Hi @patman_y 

First thing, what problem are you trying to solve?  That is, "why do this?"  Knowing that may help the community to offer other alternatives.

For example, it appears you are trying to notify the assignee and specific people when issues are "not yet started and have not been updated for the last 2 calendar days".

And so a workaround for doing that without a rule would be to create a saved filter (or more) and ask the individuals to subscribe to it for email alerts.

One downside of any email-based approach is the emails are easily ignored, or they become "noisy".  Consider instead what the root cause is for which it is believed an email reminder will help.

Back to the automation rule you describe...

This one-email-per-assignee scenario is relatively easy for Jira Cloud, but not for Jira Data Center because that version's rules do not support the advanced branch yet.

The possible workarounds depend upon how many assignees are involved and how complex you want your rules...

When you have a small number of known assignees, remove the JQL from your trigger and instead use a repeating pattern to send emails:

• trigger: scheduled with no JQL
• action: lookup issues, with JQL to find issues assigned to user #1
• if / else condition
  • advanced compare condition:
    • first value: {{lookupIssues.size|0}}
    • condition: greater than
    • second value: 0
  • action: send the email for user #1
• action: lookup issues, with JQL to find issues assigned to user #2
• if / else condition
  • advanced compare condition:
    • first value: {{lookupIssues.size|0}}
    • condition: greater than
    • second value: 0
  • action: send the email for user #2
• repeat, as needed...

This could work for up to 30 users (based on maximum possible rule size), although it would be difficult to maintain.  This rule may be made more efficient by using a single Lookup Issues action and instead using list filtering for each assignee.

When you have an unknown number of assignees, or do not want a long rule to maintain, a two rule approach may be used: one rule to start the processing and a recursive, webhook triggered rule for the rest.

1. The first rule with a scheduled trigger detects there are issues for which emails should be sent, and that rule sends a list of distinct assignees to another rule with the Send Web Request action
2. The second rule with an incoming webhook trigger processes the first assignee in the list to send the email, removes them from the list, and then recursively triggers itself.  When there are no more assignees to process, the looping halts.

This is a difficult rule set to get correct and to debug when things stop working.

Kind regards,
Bill