Aggregating Sub-task field values into Parent issue – reliable approach?

[Isabell Barsamian]

Hey everyone,

Context / Environment (System setup)

We are working with the following setup:

• Jira Service Management

• Team-managed project

• Custom workflow with a dedicated QA step

• Parent issues (e.g. “Needs Rework …”) with multiple Sub-tasks

• Automation is executed as Automation for Jira

• No marketplace apps (Automation only)

---

Custom fields involved

On Sub-tasks

• QA Classification (single select / dropdown)
  Possible values:

  • can fix

  • cannot fix

  • (empty = not reviewed yet)

On Parent issue

• QA Can Fix Count (Number field)

• QA Cannot Fix Count (Number field)

• QA Subtask Overview (Text field populated by automation)

---

Goal / What we want to achieve (shortened)

Our goal is very focused and purely aggregational:

On the Parent issue, we want to maintain two numeric custom fields:

• QA Can Fix Count

• QA Cannot Fix Count

These fields should always reflect the current aggregation of all Sub-tasks based on the Sub-task field:

• QA Classification (single select)

  • can fix

  • cannot fix

  • (empty = not reviewed yet)

Expected behavior

• When a Sub-task is set to can fix, the Parent’s QA Can Fix Count should increase accordingly.

• When a Sub-task is set to cannot fix, the Parent’s QA Cannot Fix Count should increase accordingly.

• If a Sub-task changes from:

  • can fix → cannot fix

  • cannot fix → can fix

  • or any value → empty
    the Parent counts should adjust flexibly and stay correct.

• Counts should never become negative.

---

Current problem

I’ve attached a screenshot of our current setup.

At the moment, the automation does not behave as expected:
when a Sub-task’s QA Classification is set to can fix or cannot fix, no update happens on the Parent issue at all.

The corresponding count fields (QA Can Fix Count / QA Cannot Fix Count) remain unchanged.

[Derek Fields _RightStar_]

The problem is that in your branch, the first condition controls the entire flow. If "QA Classification" = "Can fix", then the edit action will work. Otherwise, the branch will stop. You will never get to the next action in the list.

Since If/Else is not supported within a branch, you need to create two separate branches. The first handles the "Can fix" condition. The second handles the "Can't fix" condition.

Both branches will execute in your automation, but only the condition that matches will lead to the correct action being taken.

[Trudy Claspill]

Hello @Isabell Barsamian 

My recommendation is for a rule structure as follows:

TRIGGER: Work item updated
  Field to monitor: QA Classification
CONDITION: Field Value Condition
  Issue Type equals Subtask
FOR EACH: Related Issue/Parent
  ACTION: Lookup Work Items
    JQL: Parent={{issue.key}} and issuetype=Subtask and "QA Classification" = "can fix"
  ACTION: Edit Work Item
    Field to set: QA Can Fix Count
    Value: {{lookupIssues.size|0}}
  ACTION: Lookup Work Items
    JQL: Parent={{issue.key}} and issuetype=Subtask and "QA Classification" = "cannot fix"
  ACTION: Edit Work Item
    Field to set: QA Cannot Fix Count
    Value: {{lookupIssues.size|0}}

This rule will be triggered by a change to the QA Classification field, with a follow on condition to ensure it keeps running only if the change was in a Subtask type issue.

It then shifts focus to the Parent of the Subtask with the FOR EACH branch.

Within that branch the Lookup Work Items action is used to select all the children of the Parent where the children are subtasks and the QA Classification is set to "can fix".

With a Lookup Work Items action you can get the count of items found using the size attribute for the {{lookupIssues}} smart value. If no items are found then the result is null.

After retrieving that set of child issues we can use the size of the return set to set the number field in the parent.

We repeat those two steps, adjusting the JQL and the field to set, for the "cannot fix" value.

[Isabell Barsamian]

Thank you, Derek.

As recommended, I created two separate branches, but unfortunately the automation still isn’t running.
I’m not seeing any error messages that could point me toward the cause of the failure, so I currently have no indication of where the issue might originate.