- Create a new workflow with three nodes: Identity Created–>HTTP Request–>End Step - Success
- Configure the HTTP Request node to POST a text body to webhook.site with this body:
{{$.trigger.attributes.firstname}}
{{$.trigger.attributes.lastname}}
{{$.trigger.attributes.middlename}}
- Save and Test the Workflow with the default test input
Results: webhook.site will show this as being received:
{{$.trigger.attributes.firstname}}
{{$.trigger.attributes.lastname}}
{{$.trigger.attributes.middlename}}
- Edit the workflow, remove {{$.trigger.attributes.middlename}} and re-test
Results: webhook.site shows this as being received:
John
Doe
This is somewhat documented in the section on Inline Variables in Text Fields:
A syntax error in one inline variable, such as a missing bracket or including more than one variable in a single set of brackets, causes all inline variables in the field to render as plain text at runtime.
However, it doesn’t seem like a jsonPath that evaluates to null is a ‘syntax error’, and the rest of the non-null fields should still get evaluated.
Here’s an example where this causes major problems: I have to send a HTTP request to an API that includes a dozen optional parameters. If any of those optional parameters are not set (e.g. for a user with no middle name), the whole request fails because the rest of the variables are not evaluated.
This seems like a bug, right? Is there any way to address this that I’m missing? I could either write a transform that ensures that all the fields are always populated (even if it was populated with “[No Middle Name]”), or I could do some overly-complicated Workflow that uses Verify Data Type branches to check for nulls and branch to different versions of the HTTP Request based on which variables are populated (this becomes infeasible with more than a handful of optional parameters).