Access forms data with the Forms API in Jira Cloud
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Use the {{forms.last}} smart value with the Forms submitted trigger. For other triggers, use the Jira Forms API to retrieve the information you need.
Solution
This walkthrough builds an automation rule that reads form data for triggers other than 'Forms submitted'. If your rule uses the 'Forms submitted' trigger, use the {{forms.last}} smart value instead and skip these steps.
First step - Authentication
The first step is to create an API Token to be used for the authentication process.
Second step - Getting a list of forms on the work item
Now, we must list all the forms we have on a given work item. For that, we can use the following API call along with a 'Send Web Request' action:
GET https://api.atlassian.com/jira/forms/cloud/{cloudId}/issue/{WorkItemIdOrKey}/formNeeded Headers:
Authorization: Basic <token>
X-ExperimentalApi: opt-inEnable "Delay execution of subsequent rule actions until we've received a response for this web request" so the returned values are available to later actions.
Third step: Log actions!
Log actions are an essential part of all automation rules. They let us inspect variable values, action results, and so on. Here, it is a good idea to log the response from the previous action.
[
{
"id": "bc1bc47f-b192-4bde-8467-d14a5bcc9731",
"formTemplate": {
"id": "aafb5779-f76f-408f-8cc8-7e9077bc2e08"
},
"internal": false,
"submitted": true,
"lock": false,
"name": "2/14/2023 new form",
"updated": "2025-01-28T18:55:32.115Z"
},
{
"id": "53af9d19-c61d-4f61-bc36-f08891af2db7",
"formTemplate": {
"id": "b9f12dbf-7955-471a-8808-60f628f52058"
},
"internal": true,
"submitted": true,
"lock": false,
"name": "Guest wifi account form",
"updated": "2025-01-09T14:03:42.125Z"
},
{
"id": "b13e2d21-bc20-4df5-bbc8-5d199e4fd40c",
"formTemplate": {
"id": "9e63f619-03df-488e-b1c1-e1084adee4dc"
},
"internal": true,
"submitted": true,
"lock": false,
"name": "Nested form sections example",
"updated": "2025-01-31T13:02:55.289Z"
}
]Fourth step - Conditions and branching
The branch is only needed when the work item can contain more than one form. If the work item is known to contain only one form, the branch is not needed.
As you can see, we have three forms attached here. There is a simple check you can add to make sure the rule will only proceed if the work item has at least one form attached to it:
Now, we will add a branch action to loop through each of the forms (If you are sure that your work item will have only one form, this is not needed):
In this example, we're looking for a specific form named '2/14/2023 new form', so we will add a simple smart values condition to proceed only with the form we need:
Last step: Getting the form values
There is a simplified call that we can now make to get the form answers directly: Get form answers API
The returned data will look something like this:
[
{
"label": "test pdf date",
"answer": ""
},
{
"label": "what the form",
"fieldKey": "assignee",
"answer": "Wesley Nery"
},
{
"label": "Unlinked field",
"answer": "option1",
"choice": 1
},
{
"label": "This is linked to that field that prevents issue creation",
"fieldKey": "customfield_10324",
"answer": "Yes",
"choice": 10465
},
{
"label": "This is the description from the ticket",
"fieldKey": "description",
"answer": "something"
}
]The answers are returned in the order of the form template. If the form structure does not change, you can retrieve an answer by its array position. For a more future-proof approach, return the answer whose label matches the field you need:
Positional
Relies on the form template order not changing; array is zero-based, so the third field is position 2:
{{fromJson(webResponse.body).get(2).answer}}Label match
Returns the answer where the label matches, so it survives reordering:
{{#webResponse.body}} {{#if(equals(label,"Unlinked field"))}}{{answer}}{{/}} {{/webResponse.body}}Was this helpful?