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

[Tejas Patil]

Hi @Hanh Pho,
Got it, That's helpful as well.

Thanks.

[David Foote]

@Kelby Corr 

Not sure why you'd get different results. 

I'm not crazy about loading the forms page, using the developer tools, going to the Network tab, then finding 'forms' and then selecting 'Preview'. Especially when you have a huge number of forms, I think it would be easy to get the wrong form.

For me, on a test project where I had just one form, it was pretty easy to line them up and I got the same UUID via both methods:

If you have multiple forms attached to a card, you might need to use list operators to get all the ids.

[Bao Truong]

@Sam Knight You should also mention that the old method of using Jira entity properties will be removed, so people can plan to replace it. 

https://community.developer.atlassian.com/t/removing-access-to-forms-data-using-jira-entity-properties-api/80912

Also, this new way takes more time to run than the old way.

[ヴァリエンテ フロリアン_Florian Valiente_]

Trying this out now, and the smart values doesn't seem to work with fields that are using a data connection? The returned value and id for the dropdown are always blank. Same smart value on a static dropdown works.

EDIT: 2025 March 07 - created a support ticket and have confirmed it now works for fields using data connection too!

[Phong Nguyen - Atlassian Solutions Engineer]

@Sam Knight @Hanh Pho Could you please provide more clarification about this related post? https://community.developer.atlassian.com/t/removing-access-to-forms-data-using-jira-entity-properties-api/80912

We’ll soon be removing access to Forms (previously ProForma) data currently stored in entity properties from both Issue properties routes and Project properties routes.

Do we have a plan for when we will remove it? It's crucial that we prepare in advance to transition to the new methods for accessing the form data. Thank you.

[Phong Nguyen - Atlassian Solutions Engineer]

*Deleted*

[Mauricio Heberle]

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 :D

[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. 

[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:

1. In each subtask form, link the relevant fields (Name, Start Date, etc.) to their corresponding Jira custom fields.
2. Use automation or workflow post functions to copy those Jira field values from the parent task to the subtask at creation time.
3. 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:

1. The first form creates the JSM ticket.
2. Key answers are saved into Jira fields.
3. Automation attaches the second form and creates the IT sub-task.
4. The IT team opens the second form and sees values already pulled from the ticket.
5. 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:

1. 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.
2. Configure the form to create a Jira work item after submission, with those values already stored on the ticket.
3. Use Jira Automation to create the IT sub-task and attach the second Smart Form to it using automated actions
4. 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.
5. 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