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.
Join now to unlock these features and more
Hi everyone, I have been stumped over this for a while now.
I have created an automation such that when a new Issue is created and it matches an "Epic" and other criteria, a set of sub tasks will be created. The key trigger is when an issue is created.
Now, my aim is to extend this automation to when I am moving from a regular task to an epic. Initially, I changed the trigger to be multiple triggers consisting of (Issue Created and Issue moved)
Problem - This automation would not trigger when I moved an issue type from task to epic.
After some trial and error, I tested that when a task is moved to an epic, I managed to trigger "Issue created" but not "Issue moved". I tried with the multiple issues trigger and also the standalone "Issue moved" with the project being any project > project A as well as Project A to Project A. None of which triggered.
Anyone able to resolve how I can correctly trigger a automation when a issue type (Task) is moved to an (Epic)?
You can see here the current issue type = Task and I have another criteria where a field Partner Type = Payin value (I have also tested with removing this Partner type criteria and it doesn't change anything. So my suspicion is that the condition Issue type = Epic is not being triggered)
Used "Move" to change the issue type from a "task" to an "Epic"
After the issue has been moved and updated an an Epic.
Audit log shows that the criteria was not met, as mentioned above, I have tested leaving only "Issue type equals Epic" or "Issue type is one of Epic" and it will still fail the criteria.
Hi @Derrick Lim -- Welcome to the Atlassian Community!
My understanding is the Issue Moved trigger for automation rules only fires when an issue changes projects, and so that will not help for your scenario.
Next, the Issue Created trigger can fire so quickly that the data is not yet available for the rule to use. I suspect that is even more likely when only the issue type changes. The work-around for this defect is to always add the Re-fetch Issue action immediately after the Issue Created trigger. This will slow the rule by about a second by reloading the issue data before proceeding. Please try that and let me know what you observe.
Would you please post an image of that issue, NSDAT-12423, including the complete issue history information?
When I just tried an issue type change, from story to epic, for a company-managed project, it shows as an edit, and not as a new create.
When I just tested this, here is what I observe, as expected...
What you appear to be observing is when you create the issue that fires the rule. If you want to also catch the "move to epic", you would need to use the Issue Updated trigger, and check the changelog to see if the issuetype changed.
I did use that before and found that Issue updated trigger would work. However, whenever any field in the epic was updated, it would trigger despite adding the condition "If sub tasks are present, then create".
This led to child tasks being duplicated when I did not want them to. Is my condition incorrect?
Here is a Epic that already has child tasks attached, if I used the issue updated trigger with this current set of rules, the tasks would be generated again.
Let's confirm some terminology first...The out-of-the-box issue hierarchy is:
And so when using the related-issues condition to check for Sub-tasks, it will never find them as the trigger issue is an Epic. After that condition, the rule adds what appear to be new issues at the Task level. That is, children of the epic.
Instead, do you want to check if the trigger issue, epic has no "child issues"? If so that could be checked with:
I used this as suggested and it seems to work now, will test more scenarios to see if I covered all my bases.