Pass Form Data into New Ticket

[Mathew Lederman]

Hoping somebody can help, because this is a hard dependency for building out our Enterprise Service Desk in JSM.

Background: I'm trying to allow users to 'Clone' a JSM request, but present them with the populated form in a new ticket so they can make whatever changes are needed. I'm attempting to do this in a single automation rule for 120 different forms across 14 different Service Desk projects. So everything is dynamically handled through the API.

As our forms are highly dynamic, making a selection at the very beginning of the form often completely changes the subsequent fields. Actually cloning the ticket works, but then the agent sees answers from the Old form and the New form as changing options doesn't clear out the old fields.

Here's what I've tried that doesn't work:

Clone in the automation rule instead of Create New:

• New Hire A works in an office. New Hire B works remote. Otherwise they need all the same access, tools, etc.
• Manager clones New Hire A's request and changes Work Location to Remote
• Agent receives ticket A with Badge, Cube, Parking Pass
• Agent receives ticket B with Ship equipment to remote, Badge, Cube, Parking Pass even though they SHOULD only see Ship equipment to Remote.

Copying the form from A to B using the Copy Forms endpoint

• Successfully copies the form with all data from ticket A to B
• Does not bring over field data since Create New was used instead of Clone
• Changing the form from Submitted to Open for Edits wipes out all of the answers because it checks against the linked fields which are empty. 

Here's what I'm doing now:

• Get Simplified Answers endpoint to successfully pull in the answers from ticket A.
  • Save answers as a variable
• Create ticket B
• Attach the same form using Form Template ID
• Set form to customer-facing
• Set form open for edits
• Log action immediately before the PUT web request that shows the valid answers are loaded into the variable and readable.

Here's where I'm stuck

However, when I PUT using the Save Form Answers endpoint with the variable created from the initial GET, I get the following response:

• Unable to publish the web request - received HTTP status response: 400
• Error found in the HTTP body response:
• {"errors":[{"status":400,"code":"BAD_REQUEST","title":"Bad request","detail":"Invalid Json: Unexpected character ('}' (code 125)): expected a value\n at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 3, column: 1]"}]

Can anybody help or offer a better recommendation? 

[Marc -Devoteam-]

Hi @Mathew Lederman 

Am I correct here by stating, you want to clone an issue and it's form, the original submitted form on the to be cloned issue?

But you want to change the form answers changed in the from on the cloned issue?

[Mathew Lederman]

@Marc -Devoteam- You're correct. If a manager answers 40 questions to onboard user A, it would be really nice if they could simply clone that onboarding ticket and simply change the user's name and a few other details like location to onboard user B.

Multiply this across 120 different request types and you have a pretty significant time savings. 

I'm running into an issue because Cloning the original keeps all of the fields. When you change an option on a JSM dynamic form like Location from In Office to Remote, the In Office questions don't get cleared, they simply don't show up for the end-user. In the agent view, the Location would be set to Remote, but questions like Parking Pass and Desk would also be answered.

[Susan Waldrip]

Hi @Mathew Lederman and @Marc -Devoteam- , would the automation action Attach Form with Values be helpful in this case? 

[Mathew Lederman]

@Susan Waldrip it does, as the form is attached with the form fields populated exactly as desired. However, when you open the form for edits the system checks the linked Jira fields to populate the form. If you create a new ticket there are no linked fields, so the form is empty on state change. If you clone, you run into the issues I shared above.

[Susan Waldrip]

Ah, okay. Sounds like a great JSDCLOUD request, but I hope you find an answer before that's implemented. 😊

[Mathew Lederman]

It's unfortunate that so much standard functionality for enterprise-tier service desk tools is simply absent from JSM.

[Marc -Devoteam-]

HI @Mathew Lederman 

I guess the issue is only with form field that are linked to a Jira field right.

If you have form fields not linked to a Jira field, are they cleared?

If this is the case, this is an option, but I do think you make use of fields, maybe based on assets or else, that you do require for KPI's or reporting?

The API endpoint "external data" gives you all the options for the fields used on the for, it provides the configuration and options for each field on the form.

I don't think it provides the content of a submitted form.

[Olha Yevdokymova_SaaSJet]

Hi @Mathew Lederman 

Very complex case actually!

From what you described, it sounds like you may not really need a “perfect clone” of the submitted form. You need something closer to a reusable form template on the new ticket, ideally clean or only partially prefilled, so the manager can adjust the answers without old hidden fields carrying over.

One approach you could consider is Smart Forms for Jira, developed by my team. It handles forms on cloned issues a bit differently:

• New and Draft forms create fresh form instances when the issue is cloned but if some responses entered and form saved as draft it moves with that values. But if the form is new you can duplicate it and after work item cloning there will be two forms draft with values, new blank - another person can submit draft or blanc
• Submitted forms are copied as read-only responses, which is useful if you want to keep the original submission for history.
• If needed, submitted forms can also be configured to allow response editing/resubmission, depending on the workflow.

That separation can be helpful in onboarding flows like yours. For example, you can keep the original New Hire A form as the historical submitted record, but avoid bringing all of those old conditional answers into New Hire B’s editable request.

Another thing that may help: Smart Forms are reusable across Jira projects, including JSM, Jira Software, Jira Work Management, JPD, and Confluence. So you don’t need to recreate the same onboarding form separately for each service desk project. You can build one form template and reuse it across the projects where it’s needed.

So for your case, I’d probably think about it this way:

1. Keep the original submitted form on the source ticket for audit/history.
2. Create the new ticket.
3. Attach the same reusable onboarding form template to the new ticket.
4. Leave it blank, or carry over only the safe values that should always remain the same.
5. Let the manager complete/edit the new form so the conditional logic recalculates cleanly.

[Olha Yevdokymova_SaaSJet]

and also Smart Forms has auto-attach functionality so any new work item created form can be attached there automatically blank, so after work item clonning with submitted form you will have one blanc form auto-attached and one submitted form with values

[Mathew Lederman]

@Olha Yevdokymova_SaaSJet you've somewhat accurately defined the use case but missed a few key points. The cloned ticket SHOULD be an exact clone of the original, but should allow the requestor to change any and all options. This would allow the functionality to be applied globally across 90+ request types and for all users. This would also allow requestors to change only the 1 or 2 fields that are different for their new request. With the on boarding example, the only real difference would generally be the new hires name/email. However, if the requestor decides to change more options, that needs go be handled appropriately and not pass inaccurate information to the agents, which is what's happening today. 

[Olha Yevdokymova_SaaSJet]

Okay here is how it acs now but we will also have release for improving restriction of form editors
This is an example of form - saved as draft - not submitted but all draft history are visible via clock icon who modified form and how and what

This is cloned issue having exactly the same info and can be edited by anyone(video how it acts with form logic) will be further 

This is how form in draft mode acts, form logic are fully functional and fields that should be hidden via logic will be hidden and that value wont be submitted


And the final clone, the third one with submitted form, possibility to edit submtted form and all submission and drafts history

This will work the same across all projects but the only thing to keep in mind is field mapping to Jira if needed. In Smart Forms you can map any form response to any Jira field of the same type, so you need to ensure is you select mapping the priority field it should be present in this project(this wont stop the submission if not present, but it will not populate jira field with response).
Also there are posibility to select all the fields that are not used in Jira automation for example and map them to the description(very often used to avoid field creation)
Plus form fields can be form-only - visible on inside form and responses report. 

And regarding update I was talking about at the begining we are planning to release new permission scheme that will allow to select users and groups with the rights to edit all form repsonses in the exact form. This will also help with your case, because multiple user will be able to manage one form submission with different form versions. 

Let me know if there is any question regarding this, or you can also book a demo on our listing so we can show how this work with your exact scenario. Because here i limited with 30 seconds duration of gifs:)

[Arkadiusz Wroblewski]

Hello @Mathew Lederman 

Get form simplified answers returns a flattened list meant for scripting convenience, and Atlassian documents it as an array<FormSimplifiedAnswer>, with multivalue answers flattened into a comma-separated string. But Save form answers expects a request body with an answers object. Those 2 formats are not interchangeable.

The current 400 is likely because the API body is built from the wrong response format, and even after that is fixed, you may still need extra logic for conditional fields that should be cleared.

[JSDCLOUD-14757] Automatically clear value when fields are hidden in Forms - Create and track feature requests for Atlassian products.

[Mathew Lederman]

@Arkadiusz Wroblewski I had this realization late last night after I posted this. Do you know if there is a way to get the answers from a form in the format needed for the Save Form endpoint? The externaldata endpoint seems more similar, but not identical.