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

🎉 New! Access form and form fields with smart values in Jira Service Management

Sam Knight

Hello Atlassian community 👋

We’re excited to announce we’re now supporting smart values for Forms in Jira Service Management. Eliminate manual data entry and leverage dynamic data by accessing smart values on submitted forms on issues. Not only can you now retrieve form data in Jira Service Management, but can also use these values to power automations and fuel reporting. Read more about accessing smart values

Here’s how it works

Access smart values using the Forms submitted trigger

You can access submitted forms on issues when using the Forms submitted automation trigger by using {{forms}} to format the value of forms in a list when setting up a rule. To access a specific form from a list, use the automation lists smart values to retrieve the form you’re after. You can also combine, reformat, and manipulate smart values to suit your specific needs.

Example

John wants to create an automation rule that adds a comment with onboarding notes whenever an ‘Employee Onboarding’ form is submitted.

Before he creates this rule, he needs to make sure the ‘Onboarding notes’ field in the ‘Employee Onboarding’ form has a field key. He makes this ‘onboarding-notes’.

He now navigates to Automation to create this rule and selects the Form submitted as the trigger and ‘Employee Onboarding’ as the form. He then adds the action Comment on issue and enters {{forms.last.onboarding-notes}} as the comment.

Now whenever an ‘Employee Onboarding’ is submitted, the value from the ‘Notes’ field will be added as a comment on the issue.

Access smart values without using the Forms submitted trigger

You can also access any forms on an issue by using {{issue.forms.<<span data-highlighted="true" data-vc="highlighted-text"><span data-testid="acronym-highlight">UUID</span></span>>}} and referring to automation lists smart values. These will be grouped by their Universally Unique Identifiers (UUIDs) and be returned as a list. The UUID can be retrieved from either the Forms REST APIs 'Get project form index', or by inspecting elements on the Forms landing page and accessing the UUID via the Network tab.

Example

John wants to create an automation rule that adds a comment with an employee’s latest salary to an issue.

Before he creates this rule, he needs to make sure the ‘Salary’ field in the ‘Payroll setup’ form has a field key. He makes this ‘payroll-salary’.

He now navigates to Automation to create this rule and selects the Manual trigger from issue as the trigger. He then adds the action Comment on issue and enters {{issue.forms.f7142b07-d3a4-4522-a7e4-8799d526e0a6.last.payroll-salary}} as the comment.

To get the UUID for ‘Payroll setup’ form, he goes to Forms and inspects elements to find the UUID in the Network tab.

Now whenever multiple ‘Payroll setup’ forms are on an issue, the value from the ‘Salary’ field on the most recent ‘Payroll setup’ form will be added as a comment on the issue.

Let’s break down the {{issue.forms}} smart value.

What’s next?

Our team has been hard at work bringing this highly requested feature to Jira Service Management. Based on your feedback, we’ll be taking note of any future updates you’d like to see, so add comments below if you have any questions or feedback for the team.

Comments

Phong Nguyen - Atlassian Solutions Engineer

*Deleted*

Mauricio Heberle_x42e0d

Anyone else having trouble when trying to retrieve single user fields?

Thong.Tong

Accessing form field data is very useful for us. I tested this out, and the Forms Submitted trigger worked great. However, sometimes I need to use a different trigger while still accessing the form fields. So, I tested the {{issue.forms.<UUID>}} method, but when I tried to access a checkbox form field, the returned value looks like:

[value1, value2, value3]

For some reason, the brackets are automatically added. They aren't there when accessing the same field via the Forms Submitted trigger. Has anyone encountered this before, and how did you handle it?

Thank you!

David Foote

@Thong_Tong I've seen this is other places, where I expect the smart value to come back as a list, but it instead returns a string, with the brackets.

If you just want the values without the bracket, it's pretty easy to just use replace to clean it up:

{{teamsText.replace("[","").replace("]","")}}

If you need it as a proper list, for example to use in an advanced branch, you can use split on the results from the above:

{{teamsList.split(",").distinct.trim()}}

Thong.Tong

Thank you for your suggestions, @David Foote . I found my answer in Solved: Form dropdown field smart value post. Short answer to remove the brackets, use the flatten() function like

{{issue.forms.<UUID>.<Field key>.label.flatten()}}

Tobias H

Hi all!

Just throwing this in here as I had not seen any communication about it.
You no longer have to fiddle about with the Inspector tool and search the network tab for the ID, you can simply press the three dots and "Copy form ID" to swiftly get the ID for any of your automation needs

Screenshot 2025-03-27 085021.png

Kerli Suve

I believe there has been an improvement and when you are in Forms view, you can get ID from there. Easier compared to network tab or API's so if it is possible, maybe someone can update the knowledge base article too.

2026-04-15 13_14_23-Greenshot.png

Adam Sterrie

This is impressive but I am looking for something the other way around (and keep getting links to pages like this).
Can I embed a value from an issue into the form either as a default value or, better, just to display?
My use case is our onboarding process. Someone (HR) fills out an initial form and that generates a Task. Depending on what requirements the joiner has, a number of sub-tasks are created (e.g. software, hardware, access, etc), with individual forms attached to each sub-task. Currently, these forms all include fields from the parent task such as Name, Start date, and more, which the users assigned to the individual sub-tasks have to fill in. Instead, I want to display this inherited information (ideally) or at least pre-populate the values on the form to make their lives simpler.
Is there a way to do this?

Greg D

@Adam Sterrie this should be doable — are the fields on your subtask forms mapped to actual Jira fields, or are they form-only fields?

This matters because the pre-population approach relies on that Jira field link — if they're form-only fields, the values won't carry over automatically and you would need to try to copy full forms around if they are the exact same forms and that can work for you.

Assuming you can map them to Jira fields, here's the general approach:

In each subtask form, link the relevant fields (Name, Start Date, etc.) to their corresponding Jira custom fields.
Use automation or workflow post functions to copy those Jira field values from the parent task to the subtask at creation time.
Once those Jira fields are populated on the subtask, the linked form fields will be pre-populated when someone opens the form. When the form fields are linked to Jira fields, they stay in sync at each level.

To elaborate a little, you have a few options depending on your setup:

Automation rule triggered on subtask creation (good if you want to stay outside of shared workflow schemes)
Workflow post function on the Create transition (more precise control and copying is a native action from parent to subtask, but affects all work items following that workflow scheme)
If the subtask forms are identical to the parent, you could also look at copying the whole form down via automation

I know this glosses over some of the setup details, but the core idea is to get the right values into the Jira fields on the subtasks, and the forms will reflect them. Or copy the full forms around.

Hopefully this helps!

Adam Sterrie

Thanks Greg. Much appreciated.
I will look into this.
The fields are almost all Jira fields.
In our process, a user fills in an initial form (e.g. new starter joining the organisation). A ticket is created and an automation flow is triggered. The flow attaches an other form to the ticket, creates a sub-task for IT, notifies the IT department that they need to add the new starter to AD and then fill in the second form when done. (Submission of the second form then triggers the next stage, moves the sub-task to Done, and the main tocket proceeds.)
What I have now seen is that when the IT team member opens the second form, it already has most of the fields filled out using the Jira values form the ticket to which the second form is attached. This is what I was hoping for but as I am relatively new to this, I had not seen, and it is not documented anywhere (unless you can point me to the documentation I should have seen).
So it seems to be working nicely (preventing users from having to enter existing data).
Thanks again.
-Adam

Olha Yevdokymova_SaaSJet

Hi @Adam Sterrie

Yes, that behavior makes sense in JSM.

If the questions in the second form are linked to Jira fields, and those Jira fields already have values from the first form or from the created ticket, the second form can display those existing values when the IT team opens it. So in your onboarding example, details like the new starter’s name, department, start date, manager, or access requirements can already be available instead of being entered again.

The main thing to watch is the automation part. If the next step depends on the second form submission, it’s usually safest to base the rule on the JSM Form submitted trigger, or make sure the important answers are mapped to Jira fields so Automation can use them reliably in conditions and actions.

So your current flow sounds valid:

The first form creates the JSM ticket.
Key answers are saved into Jira fields.
Automation attaches the second form and creates the IT sub-task.
The IT team opens the second form and sees values already pulled from the ticket.
When the second form is submitted, Automation moves the IT sub-task to Done and progresses the main ticket.

Another approach you might consider is Smart Forms for Jira, developed by my team, especially if you want more control over this kind of multi-step onboarding flow.

With Smart Forms, you could set it up like this:

Create the first “New Starter” form set up create new work item and map key answers to Jira fields, such as employee name, department, start date, manager, and access needs.
Configure the form to create a Jira work item after submission, with those values already stored on the ticket.
Use Jira Automation to create the IT sub-task and attach the second Smart Form to it using automated actions
Prefill the second form with the Jira values from the parent ticket or related work item, so IT only completes the AD/access-specific fields.
On second form submission, use field updates or in-build in Smart Forms issue status transition that transit issue on form submission without automation and continue the flow

Welcome!

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

Quick Links

Find more posts tagged with

jira-service-desk

jira-service-desk-cloud

announcement

forms

jira-service-management-cloud

proforma

jira-service-management

form