Forms and Workflows: Text Area Field with multiple lines breaks HTTPRequest Processing (\n issue)

What problem are you observing?

When you have a Form that has a Text Area Field, that field allows multiple lines to be entered. For the purposes of this issue, a user enters in multiple lines in the field with the format:

line 1
line 2
line 3

There is an additional workflow that is triggered when the above form is submitted. This form takes the form data, and converts it to the following to store in the field variable

line 1 \n line 2 \n line 3

When this is passed into the Request Body of the HTTPRequest, it is not getting escaped like the rest of the text, so the output results in all other special characters being escaped with \\ (ie. \\" or \\n.) When the system goes to parse the Request Body after variable substitution, it fails to parse on the “\n” from the variable as it sees this as a line break instead of part of the text.

What is the correct behavior?

The system should be able to read in variable values during Variable substitution and have them get escaped properly so no errors occur.

What product feature is this related to?

ISC Forms and Workflows, Specifically Text Area Field and HTTPRequest Action.

What are the steps to reproduce the issue?

Create a workflow that triggers a form with a Text Area Field on it.
Create a second workflow that is triggered when the form is submitted and makes an HTTPRequest. The JSON Request Body can be something like this:

{
"Request_Type":"Add","Description":"Requester Details \nRequest Lines: {{$.trigger.formData.requestLinesData}} \n"Request_Group":"IT"
}

Note: Update the variable to match the form field.
Run the form workflow to trigger the form.
complete the form adding multiple lines of text
Hit submit to trigger the second workflow
View the execution log to see that it failed and then review the error.

Do you have any other information about your environment that may help?

This seems like the jsonRequestBody is getting escaped prior to the variable substitution, but the content of the variables is not getting escaped. Then the system is attempting to process the value expecting everything to be escaped, but the “\n” is causing the parsing to error.

As a workaround, we passed the formData field value into a Define Value step and use the Replace action to change “\n” to “\\n” and then pass that new variable to the HTTPRequest and it functions as it should.