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; } } }

How to access multiselect fields in Jira Automation from JSM Forms

Jonathan Porta

Hello,

I'm trying to transform a multi-select fields into labels with Jira automation.

In my automation (form submitted) I can totally access other fields from the form, like

{{forms.last.scope.label}}

But when it comes to my multi-select field called activities, the log shows absolutely nothing:

forms.last.activities:
forms.last.activities.first:
forms.last.activities.label:
forms.last.activities.labels:

I've tried different combinations but none work until now. The doc does not seem to indicate that these fields are unsupported... I really don't understand.

Has somebody a clue about what's going on?

Accepted answers

Jonathan Porta

Tragically, adding checkboxes to my form to double check if the control was faulty solved the situation...

Checkboxes work and now multiselect works also...

Jira's magic!

All comments

Jonathan Porta

Tragically, adding checkboxes to my form to double check if the control was faulty solved the situation...

Checkboxes work and now multiselect works also...

Jira's magic!

Gabriela - LeanZero

Glad you're moving again, but that wasn't magic, and the same thing will bite you on the next form unless you know where to look.

Form smart values don't resolve on the field's name. They resolve on its field key: "you'll need to know both the field type and the field key which acts as the unique identifier of a field in a form", and you set that yourself when configuring the field from the side panel. So {{forms.last.activities}} wasn't asking for your activities field at all. It was asking for a field whose KEY is activities, and if that field had no key set, or a different one, then no field matched what you typed, which is consistent with the blank you saw in the log.

That also explains why scope worked and activities didn't. Nothing to do with the field type. One of them had the key you were guessing at and the other didn't.

The trap underneath it is the strictness: "Field keys are case-sensitive so need to be entered correctly. This also includes any spaces." A key of Activities, or one with a trailing space, fails exactly the way a missing key does. No error, no warning, an empty value in the log, which is what sent you looking at the field type instead of the key.

Your syntax was right the whole time, and multiselect is explicitly covered. Multiselect dropdown sits in the group where "The following field types use the automation lists smart values and format the value of items in a list when setting up a flow", and for those the documented accessor is the one you used: "to retrieve the label of a selected choice use" {{label}}. So go and read the actual key on activities in the form builder, and if it now matches what you typed, you've found your magic.

Jonathan Porta

Badly presented but I was already referring to the field key (the last parameter of the field in the bottom right). I even removed the dash which were initially part of the key but it changed nothing.

And I stated before it worked perfectly with "scope"...

Gabriela - LeanZero

Then the key wasn't it, and my last answer was aimed at the wrong thing. You'd said the key, I explained the key back at you, which is no help at all.

With the dash detail in, what stands out is what actually made it work. Checkboxes and Multiselect dropdown sit in the same group in the docs, both under "The following field types use the automation lists smart values", so adding a checkbox shouldn't fix a multiselect that was addressed wrongly. It's the same code path. Which means the change that fixed it probably wasn't the checkbox at all, it was that you submitted the form again afterwards.

{{forms.last.activities}} reads the last submitted form, and a submission only carries the fields that existed when it was submitted. If your earlier test runs were firing against a submission made before activities was on the form, there is no activities in that payload to return, and you'd get exactly the blank you saw while scope, which was already there, resolved fine. Adding the checkbox made you fill the form in again, and that fresh submission had both.

That would also explain why removing the dashes did nothing. You were correcting the address while the data at that address was from an older version of the form.

I'm inferring that from your sequence, not reading it in the docs, so the way to settle it is cheap: leave the form exactly as it is now, submit it once more, and check the audit log for that run. If activities resolves on a fresh submission and you can also find an old run where it was blank, that's the version gap and not your syntax, and you can stop worrying it'll come back.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management