Order of operations in automation, alternative solutions

[Justus Hyytiäinen]

I have created a manually triggered automation that changes Start Date, End Date and Due Date of the trigger epic and other issues in the epic (with some conditions). After the automation has made the changes, I want to send the initiator of the automation a confirmation email with list of the issues updated. The list of issues is generated using Lookup action.

While testing this with an epic and only two issues in the epic, I ran into a problem with the email confirmation list. The list only includes the epic even though other issues have been updated as well. I've pinpointed the problem to automation order of operations: the Lookup issues action is carried out before the branched Issue field condition checks and Edit issue actions finish. Therefore, the Lookup list and the email message is missing the updated issues in the epic.

I've created a workaround using 20 something Re-fetch issue data actions before the Lookup issues action. This workaround fixes the problem at least in the scale I'm testing but I'm uncertain if this can cause some problems when scaled to epics with more issues in them. Are there some more robust and smarter ways of achieving this result available?

Please find picture of the automation rule below. For easier readability I've reduced the amount of Re-fetch issue data actions before Lookup issues to only two.

[Bill Sheboy · Accepted solution]

Hi @Justus Hyytiäinen 

By design, automation rule branches which could be on more-than-one-thing (e.g. on JQL, Issues in Epic, etc.) are run in parallel and asynchronously.  There is no guarantee of when the branch will complete...up to the very last step of the rule.

As a result, you cannot rely upon a branch completing prior to any following steps in the rule.  There is an open suggestion to add a "wait until done" for automation rule branch processing, which you may watch/vote for to see progress: https://jira.atlassian.com/browse/AUTO-32

For your scenario I suggest:

• Remove all of the Re-fetch actions
• Change the JQL for your Lookup Issues action to instead gather the epic and issues for the epic, ignoring the field changes (as they may not have occurred yet)
• Change your email body to reference the information from the manual trigger's user input fields, if possible.  If instead the rule relies upon information from the epic's changes, then consider changing your rule to
  • trigger: manual
  • conditions...to decide if the rule should proceed
  • action: use a single Edit Issue Fields to change all the fields at once
  • action: use a single Re-fetch issue
  • ...branch logic to update the child issues
  • action: lookup issues with JQL like key = {{triggerIssue.key}} OR parent = {{triggerIssue.key}}
  • action: send the email, referencing only the lookup and trigger issue fields.

Kind regards,
Bill

[Justus Hyytiäinen]

Thanks for your answer @Bill Sheboy 

"Change the JQL for your Lookup Issues action to instead gather the epic and issues for the epic, ignoring the field changes (as they may not have occurred yet)"

This was the key to fix the issue I was having. Instead of using JQL to lookup issues with the dummy field "ReschedulingHelperField" not empty, I used the same JQL here that I use earlier in the rule to determine which issues would need to be rescheduled. With this change the email confirmation might be sent before the automation carried out the changes to all the issues listed, but it will always list the same ones that have been changed or will be changed.

I've also voted on the open suggestion. It could've avoided me a lot of headache with this Automation.

[Vishal]

Hi @Justus Hyytiäinen 

I think what you need is to delay the second part of automation, which you are currently doing using re-fectch issue data, instead try to delay it as suggested in this article. This should solve your problem.

Hope it helps.

[Justus Hyytiäinen]

Thank you for the suggestion. This seems like a smarter way to simulate delay compared to mass re-fetching. However, I cannot get this method to work. I've replaced the re-fetch actions using these steps:

For the single Log action I do get webResponses printed, but the branched Log action does not work for me. There is no steps related to these shown in the Audit log, not even the steps returning empty response. This also doesn't delay the rule enough and I'm getting the confirmation email with only the epic listed.