Automation to transition epic when only one task remains that meets criteria

[Christel Gray]

Here is the user story I'm working on:

• As a user, I’d like Jira to automatically comment on QA task(s) that they can start on their task when all other tasks in an epic are completed, so I don’t have to manually add a comment telling them the task is ready for them.

I'm trying to create an automation that triggers when a non-epic issue is transitioned to either Done or Canceled. Then it will check if there are other issues that are still open in the Epic. If the only issue remaining open in the Epic has "QA" for a Component, the Epic will be transitioned to Ready to Test. If there are other issues open that don’t have “QA” as a Component, nothing will happen.

I’ve tried so many different ways, but can’t get it to work. I can show you what I’ve tried, but fear that may confuse people.

How would you solve this issue?

[Simmo]

Hi @Christel Gray,

You should be able to do this with some branching and the related issues condition:

This example needs some extra checks that @Trudy Claspill did with checking the components and not sub task, etc but this should show you how to do it.

We branch onto the epic and then use the related issues condition to check all the issues in the epic match some JQL. This is the tricky bit. The JQL then checks that the issues are all in Done (change this to your final state) OR that they are QA tasks. I can't get it to check that there is exactly one QA task.

I think this should get you to where you want to be.

Cheers,

Simeon.

[Trudy Claspill]

Ah, that's how to go back down to the children of the Epic after having branched up to the Epic from a child! Thanks for showing that @Simmo 

[Trudy Claspill]

I disagree with @Mikael Sandberg 's suggestion to not create the QA tasks until all the other tasks are done because that will impede your ability to get a complete estimate of the work effort for the Epic at the outset.

I managed to create a rule that gets most of the way there. The last thing to add is something to loop through the final set of Looked Up Issues (the found QA issues) to add comments to them. I'm sure it could use some refinement.

The first three components are ensuring that it is a transition to Done (you would need to add Cancelled) on a non-Epic, non-Sub-task issue that also does not have QA as a component.

The next step is to look for any issues under the same parent Epic that do not have QA as a component. 

Before that Component it would be good to add a condition that confirms the triggering issue actually has a parent Epic.

After doing the lookup I use a Log Action to see how many issues were found, then a Condition to proceed only if the count found is 0 (no non-QA issues remain incomplete).

Then I do another lookup to find all the QA issues that are incomplete, under the same parent as the triggering issue.

The last thing I do is use a Log Action to print out the count of QA issues found.

It is at this point you would need to add components to add a Comment to each issue returned in the last Lookup Issue action.

I was trying to do this with Branching, but I couldn't figure out how to nest Related issue branches.

[Mikael Sandberg]

So here is what I would do. I would only create the QA task(s) once all the other tasks are done, that will take some of the complexity out of the automation. So you could use the rule in the library called When all stories are completed → then close epic as your starting point, but instead of doing the transition you create the task(s). Now I realize that you may have different number of QA tasks depending on the Epic, but you could control that by using a component on the epic to control how many tasks to create.

[Mikael Sandberg]

Another option that you may have tried would be to use the same automation as mentioned above and add a second one that is an incoming webhook that does the actual lookup of the QA tasks, that way you could create them at the beginning.