Reading a Forms(Proforma) field value without the JSON tab

[#1]

 Deprecation Notice: Removing access to Forms data using Jira entity properties API

To access forms properties after the deprecation, it will be necessary to use the new feature for Forms smart-values:

• Manipulate Access smart values for forms and form fields

Alternatively, you can access these properties via the Jira Forms REST API. Here is a general guide on how you can access these properties:

1. Get the form template ID's from a project using the API below:

   https://api.atlassian.com/jira/forms/cloud/{cloudId}/project/{projectIdOrKey}/form

   This will return all the forms from your project, allowing you to find the formTemplate ID for each of them:
   
2. Accessing the forms properties of a form template:
   

   https://api.atlassian.com/jira/forms/cloud/{cloudId}/project/{projectIdOrKey}/form/{formTemplateId}

   
3. Get the form ID's from a issue using the API below:
   

   https://api.atlassian.com/jira/forms/cloud/{cloudId}/issue/{issueIdOrKey}/form

   This will return all the forms from an issue, allowing you to find the form ID for each of them:
   
4. Accessing the forms properties and responses from a form attached into a issue:
   

   https://api.atlassian.com/jira/forms/cloud/{cloudId}/issue/{issueIdOrKey}/form/{formId}

   

---

This workaround is meant to help customers who were used to working with the JSON tab provided by ThinkTilt (Proforma) and which is now being modified to use in Jira Forms. And also, to help new Forms customers to be able to get the forms fields ID.

As this feature is being changed and probably will bring support to Automation for Jira to access form contents with SmartValues. You can use the Entity Property Tool for Jira to be able to inspect the form data. This should allow you to continue to build your automation, for example.

Note: This tool is not officially supported, so please be careful how you work with these properties as you can easily break a form by changing the JSON.  

Therefore, if you don’t want to use the Entity Property Tool for Jira  and prefer to use the Proforma API, you can access the structure using the API link below:

https://<yourCloudURL>.atlassian.net/rest/api/2/issue/<issue-id>/properties/proforma.forms.i1

 Tip: The "i1" is the number of the form attached to the ticket. So if you have 3 forms attached and want to access the second, it will need to use "i2".

Important related documentation:

Use forms in Jira Service Management
How AFJ works
Smart values

Forms API for Cloud:

Work has already started on the new Forms API functionality and we now have some experimental APIs available for use. So now Marketplace Partners can already integrate forms into their products.

For more information, please refer to the features below:

•  JSDCLOUD-10671 - REST API for Proforma/Forms in Jira

 Note: Forms API are now available and documentation is available here. We are continuing to work on the functionality available which is why this issue remains In Progress.

Workaround steps:

With the Entity Property Tool for Jira installed you only will need to add the form, that you desire to get the IDs, in a ticket and go into the Entity properties tab, as I show in the screenshot below:

The structure to access data, where AAA is the question ID number (not the Question Key defined in the form builder) is:

• Text/Email/URL/Number Fields: {{issue.properties."proforma.forms.i1".state.answers.AAA.text}}

• Date Fields: {{issue.properties."proforma.forms.i1".state.answers.AAA.date}}

• Time Fields: {{issue.properties."proforma.forms.i1".state.answers.AAA.time}}

• ID of a user: {{issue.properties."proforma.forms.i1".state.answers.AAA.users.get(0).id}}

• Choice Fields: {{issue.properties."proforma.forms.i1".state.answers.AAA.choices.get(0)}}

  • Note this will only return the ID associated with the choice rather than the text.

  • The text of the selected choice value is stored is difficult for Automation for Jira to retrieve. It is stored as:
    issue.properties."proforma.forms.i1".questions.choices

About the Choice Fields property limitation, we do have an item in our development backlog aimed at improving this as well:

•  JSDCLOUD - 13694 - Forms Properties: Able to access the information and not the ID of choices fields responses

So, on the Entity property box, you will see: "proforma.forms.i1", "proforma.forms.i2"(it will probably be "1", which is a reference to the first form in the list, if it is the second form, it will be "2" then "3" and so on...):

Using a code editor like Sublime you can paste the form properties and look for the fields that you desire and get the IDs, as I show on the screen recording below:

[Amanda Ward]

Does this actually work now? All the reviews in the marketplace say this app doesn't work. 

[Bruno Altenhofen]

Hey @ama

I hope your week is going well!

The ProForma app isn’t more available on the Atlassian Marketplace. As part of the integration between ProForma and Atlassian, it is now natively available in Jira Service Management projects as the new Forms.

Also for more information on the new availabilities of Forms for JSM, JWM, and JSW products, we will be updating our users via email and also our roadmap here: Atlassian cloud roadmap

Thanks! :D

[Charles Trilha]

Nice Article!

ProForma Legend, Bruno!

[John Funk]

Hi @Bruno Altenhofen  so it is just references to these values? Or can I actually use the in the automation? For example if my automation rule looks like: 

Shouldn't that put the date from that question on the form into the Due date when the issue is created? Because if it should, that is not working for me. Same with Text fields. Is there something I am missing? 

[John Funk]

@Simon Herd 

[Bruno Altenhofen]

Hey @John Funk 

Apologies for my delay in responding to you (I was a little off in the Atlassian Community these last few days). So you can use Forms data with Automation for Jira without having to link them to Jira fields. The date field in the forms unfortunately has a limitation in that it doesn't respect Jira's default date and ends up converting it. But we have a bug already open for that:

• JSDCLOUD-11103t - Forms date format is not the same as Jira date format

So, to further clarify this matter, I went ahead and created a screen recording demonstrating how to use the form's date and date/time field without needing to link them to a Jira field in an automation rule:

• 
  
  

I hope I was able to give you a clear overview of this case and if you have any questions or need further assistance, just let me know and I'll help you!

Thanks,

[John Funk]

Hi @Bruno Altenhofen  - Super - that worked!!

Sorry, one more thing. Can you give me more detailed guidance on how the select lists should work? (including single pick list, multi-pick list, radio buttons, and checkboxes!). I want to be able to do the same thing - select the value from the form and have it populate another field - probably just a Paragraph or multi-line text field is where I would place the value. 

Thanks in advance!!

[John Funk]

Hi @Bruno Altenhofen  - Any more feedback? 

[Bruno Altenhofen]

Hey @John Funk 

So about the select lists, based on the present design, when it comes to handling/recording values chosen in choice lists(dropdowns, checkboxes, etc), ProForma keeps the choice list field ID in the JSON and returns the associated value when the form is displayed. Another bit of info you may want to know is that currently due to only getting the ID for the choice chosen(and not the answer itself), unfortunately accessing Choice list values does not work for smart values. This is a known limitation between ProForma and A4J.

Therefore, the main issue here is that the Jira Form Choice Fields type doesn’t have the "text" corresponding to the id of the option. That's why at the moment it is not possible to get the "text" but only the "choice id". For example, below I show the property of a Text Field compared to a Choice Field:

"state": {
    "visibility": "i",
    "status": "s",
    "answers": {
      "1": {
        "text": "Bruno"
      },
      "2": {
        "text": "",
        "choices": [
          "1"
        ]
      }
    }
  },

Note that the Choice Field that is represented with id 2 only has the id of the option that was chosen which is the id number "1" and the 'text' property from the Choice Fields will always be empty ("text": "",).

With that in mind, the only possible workaround is using an automation rule to override the "choice id". I made a video showing an example of how to achieve this scenario, please refer to the link below:

• 
  
  

I comprehend that this might not have been the solution you were looking for and I wish there were more I could do on my side to address this for you.

Also, allow me to share with you these feature requests that we have related to this topic:

• JSDCLOUD-10671 - REST API for ProForma/Forms in Jira
• JSDCLOUD-10697 - Forms Automation: Access form fields with smart values

Please let me know if I can be of any more help!

Thanks,

[John Funk]

Hi @Bruno Altenhofen  - though not ideal, it is definitely something that I can use and implement. Thanks for sharing!!

Will there be a Forms team from Atlassian at Team '23? I would love to meet some of you in person!

[YY Brother]

• Choice Fields: {{issue.properties."proforma.forms.i1".state.answers.AAA.choices.get(0)}}

  • Note this will only return the ID associated with the choice rather than the text.

  • The text of the selected choice value is stored is difficult for Automation for Jira to retrieve. It is stored as:
    issue.properties."proforma.forms.i1".questions.choices

Then how to use jira smart value to get the selected choice value? 

[Chetan Hassarajani]

Hello,

I have a form where i am asking the users what do they need. This is a checkbox. They can order desktop or laptop or phone or headset all 4. How do i use the entity id to find out which ones are checked. Here is what the JSON looks like.  What will follow this: 

{{issue.properties."proforma.forms.i1.state.answers.2.

      "2": {

        "type": "cm",

        "label": "I want to order the following:",

        "description": "",

        "validation": {

          "rq": true,

          "mns": 1

        },

        "choices": [

          {

            "id": "1",

            "label": "Desktop, monitor and/or accessories",

            "other": false

          },

          {

            "id": "2",

            "label": "Laptop, tablet and/or accessories",

            "other": false

          },

          {

            "id": "3",

            "label": "Smartphone and/or accessories",

            "other": false

          },

          {

            "id": "4",

            "label": "Teams headsets",

            "other": false

          }

        ],

[Mateus Martins]

Hi @Bruno Altenhofen

Are you guys planning on making it possible to retrieve the selected choice value (issue.properties."proforma.forms.i1".questions.choices)?

If so is there a feature request for me to follow up with?

Cheers

[Fabian Dengel]

Great writeup @Bruno Altenhofen , much appreciated insight and very helpful for use in Automation!

Unfortunately, the redundant mapping of choice values makes it very tricky to maintain a single-source-of-truth, so we are almost forced to fall back to mapping to a custom field and set the values there (which are then easily extracted via CF smart-value). To add on to @Mateus Martins previous comment: Any updates on that front or a request you could point us to?

Again, many thanks for sharing your valuable knowledge regarding the "under the hood" attributes of ex-ProForma :)

Cheers,
Fabian

[Bruno Altenhofen]

Hello @Fabian Dengel 

Thank you for your kind words! :D

I'm sorry to be the bearer of bad news here, but at the moment isn’t possible to manipulate the Forms Choices fields in this way.

Therefore, I've created a feature request related to this topic for our development backlog aimed at improving this as well:

• Forms Properties: Able to access the information and not the ID of choices fields responses

I'll also update this article with this feature request.
@Mateus Martins FYI

Thanks guys!

[Patricia Francezi]

Hi @Bruno Altenhofen 

Im using some of this solution to get the information from answer and using automation to populate the values in Assets objects .

The main issue currently for me is about this 

Tip: The "i1" is the number of the form attached to the ticket. So if you have 3 forms attached and want to access the second, it will need to use "i2".

I have 3 forms in my issue in a certain fase of the processes.

The second is the one of my interested.

For some reason we didnt find any information this ID may change for the same form, and we are seeing an i4 on the same form 

Second issue - the i2 is still in place, and the new one i4, have the most recent data. Do you know if this is a bug? 

Any way to not having this happening?

- The steps 

I submit  the 2nd form once i2

SOmetimes I need to reopen for edits - I reopen for customer Edits, and then the form is submited again. 

At this point, the i2 remains there in the properties, and a new one with new info is created as i4. 

The 3rd time I change the form the same way does not create a 5 or 6 id for the same form. 

With this ID changing I Cant rely in the automation for 2 reasons: 

- If i use the old id i2 it wont get the current data

- if i use 2 different automation to point to i2 and another to i4 what will happen is that depending on what was the first one worked by automaion i will have the wrong information. 

[Kyle Krug]

An additional useful reference that they don't have documented is how to reference paragraph fields. I found the below syntax works:

 {{issue.properties."proforma.forms.i1".state.answers.AAA.adf.content.content.text}}