Currently there is a workflow that has a Define Variable step to do a replace on an input from a form, then a HTTP Request to pass it along before exiting with the End Step Success. The form is not a concern here, as this issue can be seen using the Test Workflow process.
When the Define Variable gets passed a value from the form, it processes it correctly. However, if the variable does not exist in the input, such as when the user does not add input, or the field is hidden, the Define Variable instead uses the name of the variable itself (ie: $.trigger.formData.hardwareDetails)
If the value is not present in the input, a blank value, or null value should be used.
Other options:
Have the Attribute allow a default value to be configured.
Have the workflow send the field data with the Default Value configured on the field, even if hidden
Use a value such as “ATTRIBUTE_NOT_FOUND” instead of the attribute path.
What product feature is this related to?
ISC Workflows
What are the steps to reproduce the issue?
To Test:
Load the form into your Tenant (Dev works)
Configure the form to trigger on (If Required)
Configure the HTTP Request to the Webhook.site for your self.
Open the workflow in the Builder
Remove the Workaround line from the Define Variable (replace the Trigger.)
Test the workflow, but do NOT add the referenced variable to the input.
Check Webhook.site for results. See that the name of the Variable was used.
Work Around:
There is a workaround for this where you add an additional replace to replace the attribute name with another value. You need to escape the $ for it to work. You can not replace with a blank or Null value, as the system does not allow those currently. I used NONE for my example. The Workflow above is pre-configured with the Workaround to make it easier.
Do you have any other information about your environment that may help?
We see this in Sandbox because the form we use has several sections that are only shown if specific input is chose. The output to the Web Service Endpoint still expects all of the fields to be sent with blank or default data, so this issue occurs.
I found an internal ticket (PLTWRKFLW-4905) that describes a similar issue with JSONpath variables that point to a null value. It is in the pre-release phase and will be rolled out soon. Let’s see if that fixes it before I open a new ticket.
At first I thought this was not a bug and is working as designed as I had the feeling this was going to be similar to email templates, which is based on Apache Velocity logic.
This also by design sends you the variable path if the content is blank, and you can use the quiet notation if you want the value to really be empty if blank.
Basically this:
${foo}
$!{foo}
foo = “bar”
bar
bar
foo = null
${foo}
However, I have not managed to find a quiet notation for workflows. And if quiet notation is not supported or documented, then this should be indeed considered a bug.
If this should be fixed, but isn’t, what exactly was fixed?
And where was this information given to the outside world?
I mean we ask here in the forum, a ticket that we can’t see is referenced (PLTWRKFLW-4905), but we get no feedback . When the ticket PLTWRKFLW-4905 is closed, why isn’t this post being updated?
After reviewing the ticket I mentioned more closely, it is not the same. I suspect that the behavior reported by @gmilunich is by design and not a bug. If the JSONpath cannot resolve, then it remains as the JSONpath. If you would like to see it as null or some other value, then that would be a feature request.
. When the ticket PLTWRKFLW-4905 is closed, why isn’t this post being updated?