Smart Value: Retrieve the Custom Field's Name, NOT the Values

[Keiko Kamiya]

Hello,

I am trying to write a smart value to retrieve the custom field's name, but not their values for Jira automation email. 

For instance, a custom field called "Atlassian Products" and their values are Jira, JSM and Confluence, I'd like to show in the email:

Atlassian Products

• Jira
• JSM
• Confluence

When I use this format {{issue.customfield_12345.name}}, it doesn't seem to work. I prefer not to hardcode it and have it dynamically show in the email if the user selected the values under the custom field. 

Thank you for your help in advance

[Trudy P Claspill]

Hello @Keiko Kamiya 

What is the field type for which you are trying to get this information?

I tried this myself with a few field types and was also finding it doesn't work.

Subsequently I chatted with Atlassian's support channel AI and among other things got this response:

"Missing Field Metadata

While Atlassian documentation states that .name and .description return the field's label and description, this behavior is inconsistent across different field types. For fields like Number or Select Lists, the automation engine typically only loads the field's value or option data, stripping out the field-level metadata to optimize performance."

I have subsequently opened a support case providing that information back to support and asking about getting the documentation updated. I'll post back here what they say.

[Ajay _view26_]

Hi @Keiko Kamiya 

Unfortunately there isn't a direct smart value that says "give me the label of customfield_12345." The smart value system is designed around field values, not field metadata.

I know you said you'd prefer not to hardcode the field name. But as it stands, there's no {{issue.customfield_12345.fieldName}} or equivalent smart value in Jira Cloud automation.

[Marc -Devoteam-]

Hi @Keiko Kamiya 

On Data Center this was possible, but it is not in Cloud, based on open defect AUTO-1069 

As a workaround you can use a web request action in your automation based on the following API call:

https://<yourinstanceurl>/rest/api/2/issue/<issuekey>?expand=names

Add an advanced compare condition (i.e., smart value condition) to check that the request worked by checking {{webhookResponse.status}}

To get the name for a field, look it up in the names attribute of the response for your field.

For example:
{{webhookResponse.body.names.customfield_12345}}

[Trudy P Claspill]

Kudos to @Marc -Devoteam-  for finding the 2+ years old Bug about this! I had looked but did not find it.

[Andrey - Guenov Labs]

Hi Keiko — Trudy and Ajay are right that there's no direct smart value for a field's label, but there are two working routes to get it dynamically.

1. Pull the field catalogue over REST. GET /rest/api/3/field returns every field on the site with its id and name. Add a Send web request step ahead of your email, then reference the label out of {{webhookResponse.body}}. One extra call per rule run, and it means the email tracks the field even if someone renames it — which is the actual thing hardcoding costs you.

2. If the email is change-driven, {{fieldChange.field}}. On the Field value changed trigger, {{fieldChange.field}}gives the field's display name, and {{fieldChange.fromString}} / {{fieldChange.toString}} the old and new values. It's the one place Automation does hand you field metadata, so if your email fires on a change rather than on a schedule, this gets you the label with no REST call at all.

A reframe worth considering, though: your smart value already hardcodes customfield_12345. Putting the literal label next to it doesn't add coupling you don't already have — if the field is ever replaced you're editing the rule regardless. The only case where dynamic genuinely wins is a rename, which is rarer than it feels. If you're building one email, hardcoding the label is defensible; if you're generating a block across many fields, route 1 earns its keep.

For the values half of what you're after, a multi-select renders as a list, so this gives you the bullets:

<strong>Atlassian Products</strong>
<ul>{{#issue.customfield_12345}}<li>{{value}}</li>{{/}}</ul>

(use {{value}} for select/multi-select options; plain {{.}} if it's a labels-type field).

Trudy — interested to hear what support comes back with on the docs. The .name/.description documentation reading as universal when it's field-type-dependent has tripped up more than a few rules.