Automated Emails

[Amanda Sugatan]

We created a JIRA automation rule to run in the morning and send an email when a custom field 'date' is passed the date. Here' the JQL: 

project = "DCR" and "PROD Due Date" > 1 and "Status" != "DONE"

project = "DCR" and "QA Due Date" > 1 and "Status" != "DONE"

When I validated the rule, 10 issues are found. However, I received 7 emails, for each custom field JQL, and the dates passed are note the same. 

Would anyone have an idea why we are receiving so many emails?

Is it possible to customize the emails to display which issues are being found? If yes, is it possible to send an email to specific watchers based on their custom field status?

Thanks for all of your help! :)

[Bill Sheboy]

Hi @Amanda Sugatan -- Welcome to the Atlassian Community!

The reason you are receiving so many emails is the JQL is in the Scheduled Trigger, and that will process an email for each issue found.

When you want to send one email containing a list of issues meeting the criteria, please try:

• use a Scheduled Trigger with no JQL
• use the Lookup Issues action with the JQL
• filter down to what is needed, and branch to send the details using additional Lookup Issues actions

Here is an article from Atlassian that outlines the steps, which can be modified for the specifics of your scenario: 

https://confluence.atlassian.com/jirakb/automation-to-send-email-only-once-per-assignee-1310985609.html

Kind regards,
Bill

[Amanda Sugatan]

Hi Bill! Thank you for your feedback. Your response and this article was helpful in understanding what the next steps are. The JQL's in the article was hard to follow as the example rule was looking for a specific project and assignee. 

In the article, the example for Advanced Branching is this: {{lookupIssues.assignee.distinct}}, 

But would you have recommendations on what would be needed for a JQL as specific as this? project = "DCR" AND "PROD Due Date" > 1 AND status != "DONE" AND "CCO - Core Data Quality" != "TO DO" OR "IT - CS - EDB" != "QA VERIFIED"

Also, would you happen to know if it's possible to email all of the watchers on each of individual issues?

Thanks for your help! :)

[Bill Sheboy]

My apologies, as I may not correctly understand your scenario and so gave you unhelpful suggestions.  Let's try to clarify that a bit...

1) What problem are you trying to solve?  That is, "why do this?"  Who does help, how do they use the information, etc.?

2) In your solution approach, you describe sending daily email(s) when some issues match a JQL filter.  Do you want to send one email with a list of all of the issues, or one separate email for each issue?

3) You mention emails to Watchers in your response.  Are the people watching issues already using the  built-in Jira notifications to get alerts for the issues?  If so, what will they think about getting more emails?

4) Please post an image of your original rule and the audit log details showing the rule execution.  Those may provide context to help with the above questions.

[Amanda Sugatan]

Hi Bill, thank you for reaching back out. You have been so helpful and kind in helping me, so I truly appreciate your efforts!

We created a project to house issues for requests that impact about 30 teams (possibly involving 100+ people). Instead of creating subtasks for each department, we created about 30 custom fields for each team to ‘sign-off’. These custom fields have a dropdown of Statuses (ex: QA Verified, PROD Verified, TO DO,N/A) which is updated by a team manager. This is how my team keeps track of where each team is on their sign-off.

For my team specifically, we are subscribed to filters which is helpful! Currently, all the watchers are using the built-in Jira notifications – this is working great.

Originally, when I was testing the email – the rule validated, but I was getting a separate email for each issue – this is way too many emails and didn’t display which ISSUE it was referring to – so one email with a list of all of the issues would be way better!

The ideal scenario would be ..if the QA due date for these fields passed, and teams signoffs are not QA verified, an email can be sent to those specific teams that are not ‘QA VERIFIED’ as a reminder. Is this at all possible? In this case, it would be even more awesome to group the requests together where one team status is not QA verified, but if emails must be separate, that’s okay too.

[Bill Sheboy]

Thanks for the additional info, and...30 custom fields for 30 teams!  Wow, that's a lot for progress tracking. 

That field appears to be a single-select, option field, correct?

Next question: why not use a Status value and a board rather than the custom field?

Sticking with your current approach, the scenario is:

GIVEN a team named ABC
AND the team has issues which are not completed
AND the issues have QA Due Date values that are before now / today
AND the issues have a "verified" field value of To Do, N/A, or Blocked (Please verify this)
THEN send a single email listing the issues to a contact on team ABC
[ AND mark the issues to prevent sending the email again tomorrow ] (Please verify this)

For a specific team, those issues could be identified with a JQL statement.  The wrinkle is the multiple teams and one email each.

There are at least two ways to solve this:

• Create 30 saved JQL filters to find the issues, and asked the interested people to subscribe to their team's filter, on the cadence they want.  They will get an email whenever there are issues to handle.
• Create a scheduled trigger rule with no JQL, adding a lookup table to list the teams and their email recipients for the report.  Advanced branch over the table entries to gather the issues for the team with dynamic JQL and Lookup Issues.  Use a smart values condition to confirm any issues were found, and then send the email to the people noted in the table.  The rule would be less than 10 steps.

[Amanda Sugatan]

Wow this is great Bill! Aplogies for the delay - it seems for me, the more complicated something is, the longer it take ms to get back to! lol 

You definitely understand our challenges and GOAL! 

Confirmin your scenario, pelase see my comments underlined below:

GIVEN a team named ABC yes
AND the team has issues which are not completed yes
AND the issues have QA Due Date values that are before now / today
AND the issues have a "verified" field value of To Do, N/A, or Blocked (Please verify this) - YES! 
THEN send a single email listing the issues to a contact on team ABC
[ AND mark the issues to prevent sending the email again tomorrow ] (Please verify this) - YES!

[Amanda Sugatan]

Based on the two solutions - i will try to give the second one a GO as creating 30 filters in hopes someone wants to receive an email, may not be the most realistic. I'm a little hesitant because I've been having such a had time with advanced branching - would you be able to give me an example / template for the rule that I can follow by chance?

[Amanda Sugatan]

I'm trying the second solution. for the Key - does this have to match the field name? EX: CCO - Statement Ops? And for multiple team member emails - would this mean multiple lines? Thanks!

[Amanda Sugatan]

Also - does this look right to you? I'm getting an error, could you tell why? 

[Bill Sheboy]

Hi, @Amanda Sugatan 

That error indicates some type of problem with the Advanced Branch setup.  Please post an image of that one for context.

When one wants to iterate over the rows in a Lookup Table, use the entries function to access the list of values.  For example:

• action: create table named DCRSignoffPROD
• advanced branch:
  • variable name: varTeamInfo
  • smart value: {{DCRSignoffPROD.entries}}
    • in the branch, to access the table row's elements use:
      • {{varTeamInfo.key}}
      • {{varTeamInfo.value}}

[Amanda Sugatan]

Hi Bill! This has been super helpful!

I love learning the details, what does {[varTeamInfo.key/value}}  do?

here's the updated rule - it looks like this is returning with an error, would you share a suggestion on how we can fix?

Also, does the rest of the rule look OK?

Thanks so much for your help!!

[Bill Sheboy]

That looks better; the missing part with the error is because the Send Email Action does not have any Content in the message to send and that is a required field.

Regarding those smart values I noted earlier...

• You have a lookup table named DCRSignoffPROD and that currently has one row
• Each table row has a "key" and a "value" element
• In your advanced branch, the rule loops over the rows with {{DCRSignoffPROD.entries}} and names each row {{varTeamInfo}} as it loops
  • Thus to access the key from the row, use {{varTeamInfo.key}}
  • And to access the value from the row, use {{varTeamInfo.value}}

Also...your table only contains one row, which matches your condition inside the branch.  What is the purpose of that condition test?  Is it just an experiment?

[Amanda Sugatan]

Ahh okay, thank you for helping me better understand! 

I updated these two sections and deleted the extra condition (I thought I needed it to be honest) lol . 

Question - how can I refine the rule to looks for the teams and their values based on the due dates? does this rule still need adjustments for the scenario we spoke of earlier?

--added the scenario from earlier--

GIVEN a team named ABC yes
AND the team has issues which are not completed yes
AND the issues have QA Due Date values that are before now / today
AND the issues have a "verified" field value of To Do, N/A, or Blocked (Please verify this) - YES! 
THEN send a single email listing the issues to a contact on team ABC
[ AND mark the issues to prevent sending the email again tomorrow ] (Please verify this) - YES!

[Amanda Sugatan]

[Bill Sheboy]

Have you tried changing the JQL in the Scheduled trigger to limit the issues processed?

[Amanda Sugatan]

Hi Bill - thanks for your help with this - it ended up being a little too complicated so we are using a different method for outreach. Thanks so much!

Amanda