Subtask Automation

[Kerri-Anne Mak]

HI all, 

I've created an automation where when an issue hits 'in progress' status, two subtasks are automatically created

I am trying to trigger or create a separate automation for when an issue (same issue) hits the 'ready for QA' status, three different subtasks will be created. 

The problem I am having is, the 2nd rule (ready for QA) isn't executing, because of the 'issues.properies.ruleexecuted' component I have set in the 1st rule (in progress).
I added this step in case the issue goes back into 'in progress', so the subtasks won't regenerate causing duplicates. 

Is there another way around this?

Thank you for your help!!!

[Hariharan Iyer · Accepted solution]

Hi @Kerri-Anne Mak ,

Just for my clarification, does the "issue.properies.ruleexecuted equals Empty" condition exist in the second rule also, and that is why it does not get executed?

If so the simplest solution would be to use different properties for the different rules. e.g., in the "in progress" rule, you can read and set "issue.properties.inprogressexecuted", and in the "ready for qa" rule you can read and set "issue.properties.qaexecuted", and so on and so forth for other states (if you need them).

Hope that helps!

[Kerri-Anne Mak]

Hi @Hariharan Iyer

This worked!
Thank you for your help. 
I had originally set the condition in both rules, but didn't set different properties. I have now adjusted to your suggestion and it works. 

Thank you again. 

[mruttan]

A simple method to achieve this would be to count the number or subtasks on an issue before creating.  If you add a "proceed if less than 2 subtask condition" to the rule shown above, your automation will not complete.  I am using this method for a similar use-case and it is working well. 

[Bill Sheboy]

Hi @Kerri-Anne Mak 

Scenarios like this are context-specific, and your context will determine solution approaches...

Currently, the rule uses an entity property to prevent duplicating the subtasks.  To keep that approach, you would need multiple, different entity properties: one for in-progress and one for ready-for-QA.

Another approach might be driven by the count / existence of the subtasks.  For example, are the two subtasks added after transition to "In Progress" unique in some way?  If so, the rule could check for their presence instead of using the entity property check.

Then the same type of check could be done for the three subtasks added after the transition to "Ready for QA".

This approach may be better from a design perspective because the absence / presence of the subtasks is what drives the decision to add them or not.

Kind regards,
Bill