You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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:
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.
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.