Smart values for custom field with checkbox selections not working

[Jeff Koors]

I have followed the documentation for accessing smart values for list items and have tried all the different variation shown here:

Use Smart Values to Access Listed Values 

I also tried testing by having it write a log and it's not working.

The custom field is "Environment" and my selections are:

Production

UAT

Test

Development

I check the log and it says success and the result is this:

Here is a snippet of one of the smart value code I used:

The flow is this - A user fills out a support request form in the portal choosing the type of "Environment" and submits.  This is then in the body of the ticket of JSM.  I'm trying to access this checkbox value to populate into a Slack channel message.  No matter what I try, the response is empty.

Thanks!

[Jeff Koors · Accepted solution]

Darryl, 

Thanks for your help.  That too didn't work, BUT, I kept trying different variations only to find that for whatever reason "Environment" as an argument was not being acknowledged by the script.  This is what I finally landed on that worked:

{{issue.customfield_10090.value}}

I had to use the json format for custom field and that worked.   

[Darryl Lee]

Glad you figured it out. 

I'm a bit confused by your final solution though. What does that last .issue refer to?

In restrospect I should have suggested you try:

{{issue."Environment".value}}

A while back @William Sheboy figured out that for some reason, Automation requires Project Property keys to be double-quoted. Might have been worth a try in this situation too.

[Bill Sheboy]

Please note: Sometimes the double-quotes are needed and sometimes not...

Smart value expression parsing appears to use the period (.) to de-reference elements, and so when the entity property contains a period it needs to be enclosed in double-quotes.  That probably triggers some escaping logic.

I haven't clearly identified the other cases when the double-quotes are required.

__Bill

[Darryl Lee]

It sure would be nice if somebody officially weighed in and, I dunno, maybe documented this? :-}

Let's play tag! @and @Nick Menere [Atlassian] @Nick Menere @Andreas Knecht @John McKiernan 

Did I miss anybody?

[Mark Chaimungkalanont]

You should be able to use {{issue.Environment.value}} without the quotes. Quotes are only required when there are special characters (like another . ) in the name of the field

[Jeff Koors]

Your suggestion and following Atlassian's exact documentation failed every time.  See my solution below that worked.  I'm assuming that the word Environment is some sort of standard class, attribute or variable within Atlassian's code base so it's probably getting confused on how to execute.  I changed it per rest API documentation to use 'customfield_0000' and that worked.  Code recognized it and executed the automation script flawlessly.

[Jeff Koors]

@Darryl Lee sorry... my bad.  Type in the code snippet I put as my answer.  I fixed it.

[Brock Jolet]

I'm having a similar issue when referencing custom checkbox fields created for Discovery Projects. They don't appear in the instance-wide custom fields section, so I can't find the customfield_xxxx name.

When I build JQL for them, this is the correct format:

• "Teams[Checkboxes]" is not EMPTY

However, I can't figure out the smart value format. Some options I've tried to no avail:

• {{issue.Teams}}
• {{issue.Teams.value}}
• {{issue.Teams[Checkboxes]}}
• {{issue."Teams[Checkboxes]"}}
• {{issue."Teams[Checkboxes]".value}}

[Bill Sheboy]

Hi @Brock Jolet 

Smart values are name, spacing, and case-sensitive...so I recommend confirming the name when there are doubts using this how-to article.  Basically you identify an example issue which has your fields and then call the REST API with a browser tab to find the smart value.  https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Please note, unfortunately (and quite puzzlingly) there are multiple things in Jira named "Teams".  Ensure you look at all the things named "Teams" in the REST API call results to confirm it is your desired field.

Kind regards,
Bill

[Darryl Lee]

As always, "Yes And" to @Bill Sheboy.

I would actually recommend that you consider renaming your Teams Checkbox field to something like: "Teams Selection" or "Team(s)" just to distinguish from it from the Team field used elsewhere:

• The Team field is a custom field in Jira Software.  (Advanced Roadmaps)

OH but also I was going to mention that you said this:

I'm having a similar issue when referencing custom checkbox fields created for Discovery Projects. They don't appear in the instance-wide custom fields section, so I can't find the customfield_xxxx name.

Do you mean Jira Product Discovery? Ooooh, that's new to me, so I have to see what those fields look like. Maybe they're different!

[Brock Jolet]

@Darryl Lee Yes, the fields are specific to the Jira Product Discovery project they are created for instead of being instance-wide.

I am having inconsistent results in Automation when trying to access these fields. Some can be selected via Issue fields condition nodes, while others need to be referenced via JQL.

My use case for the smart value is to capture the current state of one of these fields to use later, but I'm hitting a wall just trying to reference it.

[Darryl Lee]

So, I did some actual testing (imagine that!) and created a new Discovery project. Without me customizing anything, I now see this:

But in Custom fields, I only see this:

Which leads me to believe that "Teams" was auto-created. Anyways, the technique @Bill Sheboy referenced by looking at the API endpoint for a ticket did in fact work, and I found that on my system (this will not be the same for you!) Teams = customfield_10141.

*But also*, I tested Automation and interestingly the "Field value changed" trigger gives me the option of this:

And when I chose the latter "Teams", I was able to log {{issue.Teams}} and got the value every time: Team 1, Team 2, both, or individually.

Huh. So then I noticed I can edit that field:

 

And after doing so, the option for the trigger showed deleted:

So after switching to "Teams in Discovery" I also had to change the smart value to {{issue.teams in discovery}} (it didn't seem to care about case) and it continued to return the expected values.

I would try testing outside of any branches or conditions, to see if that's the issue.

[Darryl Lee]

Oh! Looking at your screenshot:

The problem might be that you're doing this inside of a Lookup branch, in which case, you really need to be looking at:

{{lookupIssues.issue.Teams}}

Which (I THINK) will give you all of the Teams for all of the matching issues? Or you could probably more clearly list each issue with their teams with something like:

{{#lookupIssues.issue}}{{key}} - {{Teams}}{{^last}};{{/}}{{/}}

[Darryl Lee]

Or now that I look at it again, I think I misinterpreted "all match" as a lookup when it's just multiple conditions. Doh.

But yeah, are you doing this in a branch?

[Brock Jolet]

I feel silly, but you've helped me achieve my goal. My log wasn't showing any data because the field didn't have any data in it. The smart value was correct the whole time. Once I added some data, WebDev, it appeared in the logs.

Here is what I was trying to do with that smart value. I wanted to retain the existing values while adding a new value depending on external interactions. The UI doesn't have an "Add to existing values" checkbox unless you copy the data from another field. I can confirm that this setup works as intended now.

Now to figure out how to subtract values without removing all values, but I think I've got a great launching point. Thanks for the help!

[Darryl Lee]

Maybe try a simpler test first?

{{#issue.Environment.value}}

To validate that the values are showing up at all? That should generate a comma-delimited list.