Update Elements Connect multi-select field with values from children work items

[Jason Petty]

Hi Community Experts,

I have a use case that I thought might be common, but am having a heck of a time finding a solution that works. Our configured hierarchy in Jira Cloud tops out with Feature as the top level work item. Under that, we allow children work items to be Story, Defect or Task.

At the Feature level, we have a mutli-value Elements Connect field (customfield_10189)
At the the child level, we have a single-value Elements Connect field (customfield_10187)

In both cases, the data source is the same configured to pull from Assets CMDB so the values in each field are the same. One field just allows multiple values. The data contains names of applications in our company.

The goal is to have the multi-value Elements field in the Feature inherit the values from the single-select Elements fields from the child work items. This will present the user with a complete list of Impacted Applications to a Feature.

I'm successfully able to append values from one field to the other with this simple rule:

My problem is that while it adds the value no problem, when changes are made to the Application in a child work item, it just appends the list with the new value. I need it to also remove the previous value that was in the single-select while retaining the other values from the other child work items.

Perhaps an automation rule isn't the best way and there is a better way to solution this through Scriptrunner that someone is familiar with? Ideally, I think the best solution might be to clear all values in the multi-select field when any change is made to a child work item, then have it re-pull all values in. I just don't know how to handle this.

Would love to hear thoughts from an expert on this!

Thanks

[Paul Glantschnig _Appfire_]

Hi @Jason Petty and welcome to the community!

I think, the "clear then re-pull" strategy is a good one. The core issue with append-only automation is exactly what you're seeing, it has no concept of what was there before, so it can't remove stale entries.

Here's how to it should work with a single automation rule:

1. Trigger: Field value changed → your single-select Elements Connect field on child work items
2. Action 1: Look up parent (Feature) issue
3. Action 2: Clear the multi-select field on the parent — set it to an empty value
4. Action 3: Look up issues using JQL: parent = {{lookupIssues.parentIssue.key}} to get all current children
5. Action 4: For each child → append the child's single-select value to the parent's multi-select field

The key is steps 3 and 4 happening in sequence — clear first, then rebuild from all children. This way you always get a fresh, accurate list regardless of what changed.

A couple of things to watch out for:

• Race conditions: If two children change at nearly the same time, the two rule executions could overlap. To the best of my knowledge there's no built-in way to prevent this in Jira automation, but it's rare in practice. If it's a concern, you could schedule a periodic rule instead (e.g., every hour) that rebuilds all Features.
• Elements Connect fields via automation: Setting Elements Connect (Assets) fields through automation can be finicky — make sure the field accepts the value format your rule is sending. Test with a single child first before scaling up.
• Performance: With many children per Feature, the clear-and-rebuild approach triggers one write per child per change. Keep an eye on your automation execution limits.

If you find automation too fragile for this, ScriptRunner with a listener on the child field change event would give you more control, you'd write a script that queries all children, collects unique values, and sets the parent field in one operation.

That said, if the underlying goal is to see which applications are impacted across a Feature's children (rather than needing the aggregated value stored in a Jira field for JQL or other integrations), there's a simpler path.

If you're open to solutions from the Atlassian Marketplace, JXL for Jira can show this without any automation. You'd set up a sheet with your Features and their children in a hierarchy view, add the application field as a column, and immediately see every child's application value nested under its Feature.

As an example, the above gif shows parent-level aggregation of child field values in a hierarchy view with sum-ups

JXL can also aggregate values across the hierarchy with sum-ups (counts, sums, status distributions), and the view always reflects the current state of the data — no automation lag or stale values to worry about.

Cheers, Paul

Disclaimer: I'm on the JXL team.

[Ben Spillane]

Hi @Paul Glantschnig _Appfire_ 

Thanks for the additional insights. After reading your reply I found my suggested solution required a very minor tweak to become a single rule instead of two. 

Dealing with parent/child relationships in automations can be fiddly for sure. I found the "Asset objects" field type differed subtly to other select/mult-select fields such as labels.

Cheers 

[Ben Spillane]

Hi Jason, 

What you're trying to achieve is a very reasonable requirement. Standard functionality offered by Jira automations can certainly handle this scenario.

To clarify your basic scenario: 

Work Item Structure

+ Feature (Parent. An Epic by the sounds of it)

++ Defect, Story, Task (Children) 

Configured Fields

Feature

• Contains a field of type "Assets objects".
• Configured to store multiple selections.
• E.g. Field named "Impacted Assets"

Defect, Story, Task

• Contains a field of type "Assets objects".
• Configured to store only a single selection.
• E.g. Field named "Impacted Asset"

Jira Automation Details

• Trigger when Defect/Story/Task's field "Impacted Asset" is updated
  • Condition: parent must exist
• Desired outcome: Ensure parent is updated with a unique list of child "Impacted Asset" selections.
  
  

---

Working example:

My previous answer containing two automations was very easily able to be collapsed into a single rule. For completeness sake I've updated the details below.

The variable childAssetKeys and it's type/content is important:

Variable name: childAssetKeys
Smart value: {{lookupIssues.customfield_10470.key.distinct().flatten()}}

Automation rule notes: 

• Ensure rule trigger scope, trigger conditions, and conditional logic is limiting execution as much as possible.
• The ability to work with an items parent is intentionally limited in automations; with primary access being via branching. For example, direct smart value access to {{issue.parent.key}} is limited to sub-tasks.
• The automation rule applies a single edit work item action to set the "Impacted Assets" field based on child selections.
• Race conditions: as mentioned by others these are possible albeit rare in practice.

I hope this approach helps, or at minimum exposes some additional automation "tricks" that might be of current or future value.

Note: The above all assumes the correct configuration of fields, screens, access etc.

Regards, 

Ben