Jira cloud Automation Add numeric field values of multiple tasks to one field linked via "Parent of"

[Adam LaCoste]

Hi All, 

I am attempting to combine several different custom field values from several different sources into one field of a linked issue and hope someone can help me.

Source Task 1 Custom fields (Child of) = 25

Source Task 2 Custom fields (Child of) = 139.5

Source Task 3 Custom fields (Child of) = 40

etc.

Update Task Custom field (Parent of) = sum of Task Source Custom fields (Child of)

[Bill Sheboy]

Hi @Adam LaCoste 

What have you tried thus far to solve this need?

If you have started an automation rule, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Until we see those...

If you can write JQL to gather the issues, you may use the Lookup Issues action to gather them and sum the field.

Kind regards,
Bill

[Adam LaCoste]

Thanks Bill,

Here is a bit more context.

The initial approach was to gather the time logs from all tasks - Epic to Sub-Task.  That was achievable using the "lookup/sum" approach but then we discovered that some teams were using a makeshift fourth tier.

Epic > Stories (epic linked) <-> (Parent of/Child of) <-> Tasks (not epic linked)> Sub-Tasks 

So we lost the Epic Link qualifier and were only retrieving information to the Task level with the Epic Link allocated.

Recent attempt was to pull in all Tasks trigged from the Story > "Parent of" approach.  This pulled in the custom field values that we were looking for but from that point I cannot seem to:   sum up the lookup results and apply that value to a custom field.

[Bill Sheboy]

Because of that extra layers added (i.e., putting Tasks under Stories...) that is not easily done in one automation rule.  The reasons are: branches cannot be nested, and branches execute in parallel (and thus will not finish before the next steps in the rule).

Your possible work-arounds are to:

• Split this up in to multiple rules for different pair / levels, where when a the "Task level" field is updated, that triggers another rule, and so on.  This may cause more rule executions, but as you appear to be on a Premium license that may not be a concern.
• Attempt to create a dynamic JQL statement based on linking so the issues can be found in one lookup.  That is very challenging to build correctly, even if you have marketplace addons to extend JQL.
• Talk to the team to understand why they are working that way, and perhaps reduce the number of levels.  (My hypothesis is if they are bringing the Story level into sprints they have a lot of issue carry-over, sprint after sprint.)

[Adam LaCoste]

Thanks Bill.  I appreciate your insight sir.  I'll give it a shot using multiple rules and get back to you.

[Hannes Obweger - JXL for Jira]

Hi @Adam LaCoste

have a look at this recent thread; while the thread refers to estimates, you should be able to achieve the same for your custom fields (both using the Automation approach, and using Advanced Roadmaps or selected Marketplace apps): https://community.atlassian.com/t5/Jira-Software-questions/We-need-Epic-to-summarize-task-time/qaq-p/2516951

Hope this helps,

Best,

Hannes

[Adam LaCoste]

Thanks Hannes, 

The initial approach was to gather the time logs from all tasks Epic to Sub-Task.  That was achievable using the "lookup/sum" approach but then we discovered that some teams were using a make-shift fourth tier.

Epic > Stories (epic linked) <-> (Parent of/Child of) <-> Tasks (not epic linked)> Sub-Tasks 

[Hannes Obweger - JXL for Jira]

Hi @Adam LaCoste

right, yeah that makes it a bit trickier. I trust that you'll sort out the Automation logic with Bill. Just if our app, JXL for Jira, is an option for you: This would be easy to solve here, as issue hierarchies can be defined based on Jira's built-in parent/child relationship (like epic/story and story/subtask), and/or based on issue links (like parent of/child of).