Hi dear Community, I'm stumped that I can't get the solution of How-to-combine-values-from-various-multiple-select-fields to work in my usecase. The setup: The problem is quite similar to the question linked above. I have a top-level Movement issuetype that has children of the Initiative issuetype. On both the Movement and Initiative issuetypes I have the same custom field (customfield_10301, which I'll call "Domain" in the rest of this post) that is a multiselect list with five possible entries (call them A, B, C, D and E). My Goal: If the Domain entry of one of the Initiatives changes, I need to reflect that change in the value of the Domain entry that resides on the parent Movement Jira item. Example: Initiatives 1 and 2 are children of Movement X , and their customfield is filled like this: Initiative 1 Domain: A, B, D, E Initiative 2 Domain: A, C Movement: Domain: A, B, C, D, E If the Domain value of initiatieve 1 changes to A, B, D, Movement X to be filled with: A, B, C, D (which is a logical "or" executed on the values of the Domains of its children). Step by Step: 0: The trigger of the automation would be a change in the Domain value of an Initiative * When: Value changes for Domain Followed immediately by the check if it's an Initiative that we're dealing with: * If: Issue Type equals Initiative And checking if the Initiative indeed has a parent Movement * If: Compare two values: Check if: {{triggerIssue.parent link}} does not equal Empty 1: As per @Bill Sheboy's solution in the link above, I first lookup the issues: * lookupIssues JQL: 'parent link' = {{triggerIssue.parent link}} And I verify the lookup by logging it (the correct issues are looked up) using * Add value to the audit log: Looked Up are: [{{lookupIssues.key}}]. This indeed gives me the initiatives that are children of the parent Movement of the trigger Initiative (the square brackets are there to more easily see an empty result). 2: I then branch into the parent Movement by * For JQL issue = {{triggerIssue.parent link}} and then apply the magic in Bill's solution by editing the Movement using the more options and then Json with the smart values on the looked-up Jira items: { "update": { "customfield_10301": [ {{#lookupIssues.customField_10301.value.flatten.distinct}} { "add": { "value": "{{.}}" } } {{^last}},{{/}} {{/}} ] } } 3: As you might've guessed (if you've read so far), the magic didn't happen in my case. I've been dabbling with creating variables inside the automation and writing their content to the audit log, to find out what is going on. It seems that as soon I'm using either flatten or distinct, I end up with an empty Domain value. What am I missing here? Kind regards, Dick

Hello @Dick, Your diagnosis looks right to me: on Data Center, the Lookup Issues action only exposes a limited set of stock fields, so {{lookupIssues.customfield_10301}} comes back empty no matter what you chain after it. That matches the open suggestion you linked, and it explains why the same rule works for @Lalithesh on Cloud. Since you're heading down the web request route, the shape that should work on DC: * Send web request (GET) to /rest/api/2/search?jql='parent link' = {{triggerIssue.parent link}}&fields=customfield_10301, with "Delay execution" enabled so the response is available to later steps. * Build the union from the web response smart values (the option values sit in the response JSON under fields.customfield_10301[].value). * Send web request (PUT) to /rest/api/2/issue/{{triggerIssue.parent link}} with the update JSON in the body. Use a dedicated service account token for the auth header rather than a personal one, and log {{webResponse.status}} to the audit log while testing. The exact smart value names vary a little between DC versions, so verify them with an audit log entry first. Best, Ivan

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Combining values from a bunch of Jira Items with a multiple select custom field.

Dick_uzl964

Hi dear Community,

I'm stumped that I can't get the solution of How-to-combine-values-from-various-multiple-select-fields to work in my usecase.

The setup:
The problem is quite similar to the question linked above. I have a top-level Movement issuetype that has children of the Initiative issuetype. On both the Movement and Initiative issuetypes I have the same custom field (customfield_10301, which I'll call "Domain" in the rest of this post) that is a multiselect list with five possible entries (call them A, B, C, D and E).

My Goal:
If the Domain entry of one of the Initiatives changes, I need to reflect that change in the value of the Domain entry that resides on the parent Movement Jira item.

Example:
Initiatives 1 and 2 are children of Movement X , and their customfield is filled like this:

Initiative 1 Domain: A, B, D, E
Initiative 2 Domain: A, C

Movement: Domain: A, B, C, D, E

If the Domain value of initiatieve 1 changes to A, B, D, Movement X to be filled with: A, B, C, D (which is a logical "or" executed on the values of the Domains of its children).

Step by Step:
0: The trigger of the automation would be a change in the Domain value of an Initiative

When: Value changes for Domain

Followed immediately by the check if it's an Initiative that we're dealing with:

If: Issue Type equals Initiative

And checking if the Initiative indeed has a parent Movement

If: Compare two values: Check if: {{triggerIssue.parent link}} does not equal Empty

1: As per @Bill Sheboy's solution in the link above, I first lookup the issues:

lookupIssues JQL: 'parent link' = {{triggerIssue.parent link}}

And I verify the lookup by logging it (the correct issues are looked up) using

Add value to the audit log:
Looked Up are: [{{lookupIssues.key}}].

This indeed gives me the initiatives that are children of the parent Movement of the trigger Initiative (the square brackets are there to more easily see an empty result).

2: I then branch into the parent Movement by

For JQL
issue = {{triggerIssue.parent link}}

and then apply the magic in Bill's solution by editing the Movement using the more options and then Json with the smart values on the looked-up Jira items:

{
"update": {
"customfield_10301": [
{{#lookupIssues.customField_10301.value.flatten.distinct}}
{
"add": { "value": "{{.}}" }
} {{^last}},{{/}}
{{/}}
]
}
}

3: As you might've guessed (if you've read so far), the magic didn't happen in my case.

I've been dabbling with creating variables inside the automation and writing their content to the audit log, to find out what is going on. It seems that as soon I'm using either flatten or distinct, I end up with an empty Domain value.

What am I missing here?

Kind regards,
Dick

Accepted answers

Ivan Manolov _Appfire_

Hello @Dick,

Your diagnosis looks right to me: on Data Center, the Lookup Issues action only exposes a limited set of stock fields, so {{lookupIssues.customfield_10301}} comes back empty no matter what you chain after it. That matches the open suggestion you linked, and it explains why the same rule works for @Lalithesh on Cloud.

Since you're heading down the web request route, the shape that should work on DC:

Send web request (GET) to /rest/api/2/search?jql='parent link' = {{triggerIssue.parent link}}&fields=customfield_10301, with "Delay execution" enabled so the response is available to later steps.
Build the union from the web response smart values (the option values sit in the response JSON under fields.customfield_10301[].value).
Send web request (PUT) to /rest/api/2/issue/{{triggerIssue.parent link}} with the update JSON in the body.

Use a dedicated service account token for the auth header rather than a personal one, and log {{webResponse.status}} to the audit log while testing. The exact smart value names vary a little between DC versions, so verify them with an audit log entry first.

Best,

Ivan

All comments

Gor Greyan_wzwybp

Hi @Dick

I think the issue is with the structure returned by the multi-select field, not the lookup itself.

lookupissues gives you a list of work items, and each work item has its own list of Domain options. So effectively you have a list of lists. You need to flatten that collection first and then apply distinct.

I would first test this directly in the audit log:

With your example:

Initiative 1 --- A, B, D
Initiative 2 --- A, C

This should return

A, B, D, C

I found that funcitions here.

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists

One thing I would change in your JSON is that you're using the option values to build the update manually. For a multi-select field, I would first confirm exactly what Automation is returning before constructing the JSON.
Please set these 3 logs; they will tell us at what level the value becomes empty.

{{lookupIssues.customfield_10301}}
{{lookupIssues.customfield_10301.value}}{{lookupIssues.customfield_10301.value.flatten().distinct}}

Regards,
Gor

Lalithesh

Hi @Dick

I was able to reproduce the automation using the details shared here, and it worked without any issues.

Automation screen grab for reference Screenshot 2026-08-28 114743.jpg

Cheers!

Lalithesh

wee change to the Edit action: the update function will only add value but it will never remove values that are removed from the child tasks.

Use this JSON instead

{

"fields": {

"customfield_xxxxx": [

{

"value": "{{.}}"

}{{^last}},{{/last}}

]

}

Dick_uzl964

Hi there, @Lalithesh.

It seems that you use Jira Cloud. I'm using Datacenter version 10.3.24 (indicated in the tags on the right). I'm sorry, but I'm not particularly looking for a confirmation that the solution works in Jira Cloud.

Hi there, @Gor Greyan

I noticed the extra parenthesis after flatten(), which were neither present in the referred, nor my solution. That would be a good catch, I'll try it and report back.

Thank you both for your efforts regarding this.
Kind regards,

Dick

Dick_uzl964

These pictures contain the test Gor asked. The parentheses after flatten are not making a difference.

I'm now suspecting our underlying Java (openJDK-21).

Kind regards,
Dick

Automation - Flatten Audit Log.png Automation FlattenChecked.png

Lalithesh

Ah okay. Apologies, I missed the tags

Dick_uzl964

Ow bummer: Lookup issue action - Add support for more fields on JIRAAUTOSERVER-877

this should've been tackled for Jira Datacenter 3 years ago...

My list is empty to begin with!

Dick_uzl964

Going for the How to sum story custom filed values to an epic? solution using web request to the REST API mentioned in the comments by Bill.

Gor Greyan_wzwybp

Hi @Dick

Thanks for the reply.

The interesting part of your audit log is that the lookup itself works correctly, while the Domain expression is already empty before distinct really becomes relevant.
I would therefore go one level simpler and inspect how Automation for DC is exposing this particular multi-select field.
Could you try logging these directly, without flatten or distinct? {{triggerIssue.customfield_10301}}
{{triggerIssue.customfield_10301.value}}

and, after the Lookup

{{lookupIssues.customfield_10301}}
{{lookupIssues.customfield_10301.value}}
I'd use the field ID rather than Domain for this test, just to remove field-name resolution from the equation.

Regards,
Gor

Ivan Manolov _Appfire_

Hello @Dick,

Since you're heading down the web request route, the shape that should work on DC:

Send web request (GET) to /rest/api/2/search?jql='parent link' = {{triggerIssue.parent link}}&fields=customfield_10301, with "Delay execution" enabled so the response is available to later steps.
Build the union from the web response smart values (the option values sit in the response JSON under fields.customfield_10301[].value).
Send web request (PUT) to /rest/api/2/issue/{{triggerIssue.parent link}} with the update JSON in the body.

Best,

Ivan

Ivan Manolov _Appfire_

Following up on my earlier answer, @Dick: depending on why the Movement needs the combined value, there may be a way to skip the write-back entirely. If you're open to using an app from the Atlassian Marketplace, JXL for Jira can help with this. Specifically, its formula columns allow you to compute the union of the children's Domain values live on each Movement row:

const values = this.hierarchy.children
  .flatMap(c => c.domain ?? [])
  .map(o => o.value);
return [...new Set(values)].join(", ");

It runs on Data Center, and the Movement > Initiative relationship works through the same Parent Link your hierarchy already uses. The computed value updates as Initiatives change and comes along in exports. The caveat: it's a display column, so if other JQL or boards must read the real Domain field on the Movement, your REST route is still the right call.

Disclosure: I work for the team that builds JXL.

All the best,

Ivan

Dick_uzl964

Hi @Ivan Manolov _Appfire_,
A couple of things I would like to mention:

First: please say hello to Hannes from me We did some debugging on JXL together.
I need the value stored on the movement as I use it to gather Jira Items for displaying purposes, so I need to get the REST route working.
jql='parent link' = {{triggerIssue.parent link}} returns an error "URL failed to Parse" in the Send web request, with a remark that I should use: {{value.urlEncode}} for the smart value. This sadly doesn't port to the {{ }} in the jql, neither when I first declare the MovementKey variable as MovementKey = {{triggerIssue.parent link}} and then use {{MovementKey.urlEncode}} in the jql.
The single quotes around parent link are a god-sent to me. Thank you for that.
The Atlassian suggested usage double quotes on the "how to get the url-friendly version using the url of an issue search action" didn't work.

So the story to nailing this continues.

Kind regards,
Dick

Dick_uzl964

Tiny result
Using:
<our instance>/REST/API/3/search?jql=%27parent%20link%27%20%3D%20{{MovementKey}}

gives me a Response 200 and a

Request GET with the complete path

The {{webhookResponse.body}} however contains a lot of stuff that isn't related to specific Jira Items. Even this came along:

{{webhookResponse.body}}

{\u0022product\u0022:\u0022jira\u0022,\u0022destination\u0022:\u0022/REST/API/3/search?jql\u005Cu003d%27parent%20link%27%20%3D%20DIR-1\u0022,\u0022forgotLoginDetailsUrl\u0022:\u0022/secure/ForgotLoginDetails.jspa\u0022,\u0022signupUrl\u0022:\u0022/secure/Signup!default.jspa\u0022,\u0022permissionsViolationContext\u0022:{\u0022showLoginForm\u0022:true,\u0022warningMessages\u0022:[\u0022\u005Cu0027starm001\u005Cu0027 does not have permission to access this page.\u0022,\u0022If you think you shouldn\u005Cu0027t get this message, please contact your Jira administrators.

DIR-1 is indeed the MovementKey. But I'm admin of this Jira instance, and all the projects that are in scope of the Automation that runs the Webrequest. I'm a bit baffled by the permissions violation.

Here's hoping
Dick

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-server

jira-data-center

data-center

select-list

multi-select

smart-value