Inline variables in Workflows text fields that evaluate to null values prevent other variables from being evaluated

  1. Create a new workflow with three nodes: Identity Created–>HTTP Request–>End Step - Success
  2. 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}}
  1. 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}}
  1. 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).

1 Like

Thank you for bringing this to our attention Brad. A bug report has been created for the engineering team (PLTWRKFLW-2609). I’ll respond to this post once a fix is released.