Automation to find Features / Initiatives without child issues failing

[Kunal Dhir]

Hi, I am trying to follow this automation example (provided by Jira knowledge base support) to find Epics without child issues but do it for Features / Initiatives. This isn't working for me as it is also returning results with child issues

This example comprises of 2 automation rules - one to find the issues without child issues and the other one to email them. I think the problem is in the first rule. 

Rule 1 

My Implementation 



Trigger

Condition

Action

I think the problem lies with the disconnect between the condition and the action. Right now it checks for the condition but performs the action for all results. I cannot find a way (either though branching or condition) where it should perform the action on only the results matching the condition. I already know that the parent field route doesn't work.

Happy to provide more context or if you have any other way of finding Features / Initiatives without child issues. 

[Bill Sheboy]

Hi @Kunal Dhir -- Welcome to the Atlassian Community!

The article you linked to uses Epics and the built-in parent field for the relationship between children and their parent, Epic.

You appear to be Premium license level, and so I wonder: did your site admin configure the hierarchy such that the parent / child relationship is correct for your Features and Initiatives?  If not, that branch will not work the same as shown in the article.

Also, that article just shows a count value of 0 or unknown / not-defined for the counts.  Another rule (or modification of it) would be needed to store the actual children count, likely using the Lookup Work Items action to update each Initiative whenever a change happens to the children.

Kind regards,
Bill

[Kunal Dhir]

Hey Bill, 

Thanks so much for your response. The hierarchy is set such that Initiatives can be parent of Features and Features can be parent of Epics. 

For the storage of children count suggestion, I am a bit confused. Could you elaborate a bit more? Coz in my understanding I am only interested in Features without child issues (so the field is set to 0 for these features) and then I can get results based on this field. How would it help my case to store the number of child issues?

Right now what's happening is that the field is being set to 0 for all Features coz the branching is not set between the condition and action. This is where I am struggling.

Hope I was able to clarify my problem. 

[Bill Sheboy]

Thanks for clarifying, @Kunal Dhir as I did not know if you needed the actual count or just the 0 indicator.  (There are several related knowledgebase articles for setting such counts.)

For the rule you show, the Scheduled Trigger use JQL to find issueType = Feature.

But you describe Initiatives are the parent, so shouldn't that JQL start with Initiatives to then count the children which are Features?

As written, that rule will check for child Epics of the Feature instead.

[Kunal Dhir]

Hey Bill, I am looking for the rule to work for both scenarios where it finds Initiatives wihtout any child features and Features without any child epics.

[Bill Sheboy]

In that case, the JQL should contain both work item types.  Without seeing all of the JQL as it is concealed, an example might be:

project = myProject
 AND issueType IN ( Feature, Initiative )

[Kunal Dhir]

I understand that. There is a separate rule I have running for Initiatives(facing same issue). This one is just for Features. My issue as I have mentioned previously is the disconnect between condition and action.

Unless, I am completely missing your point. 

[Bill Sheboy]

Okay, resetting a bit...Let's confirm a key assumption: are all of your work items in one single Jira project?

If not, what is the scope of your rule in the details at the top: single-project, multiple-projects, or global?

A single-project scope rule cannot see the work items in other projects, and so the result of that child condition check will always pass as true.  The fix for that is to work with your Jira Site Admin to change the rule scope to what is needed: specific multiple-projects or global.

[Kunal Dhir]

Hey Bill, for this rule the scope is a single project. 

[Bill Sheboy]

Thank for confirming that all of the work items (parent and children) are in the same Jira Project.

Next thing to try: let's assume the Child condition check does not work as expected.

We can test that by disabling your current rule and performing the check using the Lookup Work Items action instead with a new rule:

• trigger: scheduled, with JQL of
  • parent = yourProject AND issueType=Feature
• action: lookup work items, with JQL of
  • parent = {{issue.key}}
• smart values condition:
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 0
• action: edit work item, setting your custom field to 0

I recommend testing that rule with a single Feature, perhaps by adding its specific key to the trigger JQL.