How to set automation to edit tasks/sub-tasks of Epics (i.e., all child issues)?

Ahmet Fatih Ayyıldız March 5, 2024

This automation will help me edit all Child issues of Epic, whether tasks or sub-tasks, when the specific field of Epic changes.

Further context:

It is related to my Issue Security needs. Epics (and their child issues) will be visible to only the selected people who frequently change. 

Since Issue Security applies to all tasks/subtasks of that Epic, I need automation to edit the "User Picker" custom field for all Child issues when the same field in the Epic changes. Whoever is in this custom field will have access to view all tasks.

But I need help getting this automation to work for sub-tasks. It only works for tasks.

Even when I change the "For Children" branch to "For Sub-tasks," it doesn't work.

I am lost in understanding why Epics and their parent/child relations cause so many problems at every step of my journey. I am trying to remember a scenario where the Epic's structure felt complete.


1 answer

1 accepted

2 votes
Answer accepted
John Funk
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 6, 2024

Hi Ahmet,

I think the problem lies in fully understanding the structure. Tasks are children of Epics. Sub-tasks are children of Tasks, not Epics. I guess you could say they are grandchildren. So the automation is only going to go one level deep. 

You can accomplish this by creating a second rule where the Condition is for Task (and Story or any other Level 0 issue type). 

So when the Epic fires, it will update all of the child tasks. This will trigger the second rule based on the Task getting updated and will update all of the Sub-tasks. Make sure the box is check on the Rule Details page to allow the rule to be executed by another rule. 

Ahmet Fatih Ayyıldız March 6, 2024

Thank you, John; I think I get it.

I would have loved to solve this under only one rule, though. 

Like John Funk likes this
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 6, 2024

Hi @Ahmet Fatih Ayyıldız 

Adding to John's answer, and following up on your note about trying one rule:

That may be possible, although it is a bit more complicated.  There is a limitation that this can only work for up to 100 issues.  If you have more, please use the 2-rule approach John describes.

The idea is to gather the all keys of the impacted issues first, and then use a JQL branch over them.  This can be done using the lookup issues action.  For example:

  • trigger: your field changed
  • condition: issue type is epic
  • action: lookup issues, with JQL to find the child issues of the epic
  • smart value condition: confirm there were results in the lookup
  • branch on JQL:
key IN ( {{#lookupIssues}}{{key}}{{#subtasks}}, {{key}}{{/}}{{^last}}, {{/}}{{/}} )
  • action: edit the issue's field

That smart value expression in the JQL grabs a child issue key, adding any subtask keys.  Please look here to learn about list iterators:

Kind regards,

Like Ahmet Fatih Ayyıldız likes this
Ahmet Fatih Ayyıldız March 6, 2024

Hello Bill, thank you for your detailed answer. 

I will definitely look into it.

Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
Site Admin
AUG Leaders

Atlassian Community Events