Unable to match IssueType=Epic criteria when moving from a non-Epic to Epic

[Derrick Lim]

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.

[Bill Sheboy · Accepted solution]

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.

Kind regards,
Bill

[Derrick Lim]

Seems like re-fetch isn't the main issue, the main issue is that the conditions are not matching. Though I don't understand how the "Issue type is one of Epic" or "Issue type equals Epic" doesn't trigger even when the issue type is indeed an Epic after moving.

[Derrick Lim]

Adding on, the automation works when I create a new epic directly, so the criteria matches. It just somehow doesn't fulfil the criteria when its moved...

[Bill Sheboy]

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.

[Derrick Lim]

Here's a new issue I created as a task then moved to an epic.

[Bill Sheboy]

When I just tested this, here is what I observe, as expected...

• when: create a new story
  • a rule with an issue created trigger runs
  • a rule with an issue updated trigger does not run
• when: move the story to change the type to epic
  • a rule with an issue created trigger does not run
  • a rule with an issue updated trigger runs

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.

[Derrick Lim]

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.

[Bill Sheboy]

Let's confirm some terminology first...The out-of-the-box issue hierarchy is:

• Epic
  • Story, Task, or Bug
    • Sub-task

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:

• a related issue condition with JQL of parent = {{triggerIssue.key}} AND issueType = "New Integration"
• a lookup issues with JQL, followed by an advanced compare condition to see if the returned issue count is 0
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 0

[Derrick Lim]

Understood now.

I used this as suggested and it seems to work now, will test more scenarios to see if I covered all my bases.

• a related issue condition with JQL of parent = {{triggerIssue.key}} AND issueType = "New Integration" and condition is not present
• a lookup issues with JQL, followed by an advanced compare condition to see if the returned issue count is 0
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 0