Automation - getting blank space instead of date in Summary

[Andrew Zabrzeski]

EDIT: Solved! See below.

Hi everyone!

I'm very new to JSM and Automation, but since searching online didn't get me an answer, I thought I'd post here.

I would like to set up a request form for onboarding. I used the default template, modified that, all good so far. To make lives easier for IT I would like to modify the Summary field to be such:

Onboarding order - [Starting date] - [Name]

I got the name down, but instead of the starting date value, I'm getting a blank space (see the screenshot).

The Automation bit that sets the Summary is set up like that:

Step 1 - create variable

Variable name: onboardingSummary

Smart value: Onboarding order - {{issue.Start date}} - {{issue.First Name}} {{issue.Last Name}}

Step 2 - edit issue fields

Summary equals {{onboardingSummary}}

I thought I'd need to dig in to get the value of the field, but the API call returns just this:

"customfield_11159": "2025-03-20",

so I have nothing like .name or .value to grab.

I'm now assuming that I need to convert the date object into string, but I couldn't find any such method in the documentation.

Any help appreciated!

Solution

I just had a lightbulb moment - replaced the name of the custom field with it's, I don't know how to call it, "API name"? So that this:

{{issue.Start date}}

became this:

{{customfield_11159 date}}

and now everything works.

Would be cool, though, if the Community could tell me:

1. What's the proper name for the "customfield_11159"? So that in the future I can call it correctly and not get it confused with the display name on the form.

2. Is there a way to expand the custom field to have that user friendly name included? It would 100% help with readability when reviewing rules a year from now.

[Bill Sheboy · Accepted solution]

Hi @Andrew Zabrzeski 

Smart values are name, spacing, and case-sensitive, and often do not exactly match the field display names on the pages.  And for some fields in rules, the custom field ID is required rather than the smart value by name.  Unfortunately, even that is not consistent: sometimes the name is required for things like the changelog smart value but the custom field ID is required for an edit.

I recommend checking the smart values using this how-to article to learn if there is a supported smart value name for your fields.  You can tell if only the ID is used for edits by using an example issue to find if the value is set to the name or the custom field ID in the JSON.

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Kind regards,
Bill

[Andrew Zabrzeski]

Hi @Bill Sheboy - thank you, this is essentially exactly what I used and did.

[Paul Wiggers · Accepted solution]

Hello,

Good to see that you have resolved this yourself and thank you for sharing the solution!

About your questions:

1. I'm afraid that this is it. You can refer to custom fields by their number and this is the correct way. If you want to keep track of what is what you might be able to abuse the "Log Action" action step to document what your custom field is named, or you can mention this in the description of the automation.
   
   
2. See above

I hope this helps a bit.