Data Actions will ignore null input values


Data Action execution and test requests will ignore null input values. This is the current behavior experienced in the UI test mode and when executing and testing data actions through the Public API. This will eliminate data action execution failures due to inconsistent null value behavior between different architect flow types.

Change Category


Change Context

Customers have experienced difficult-to-troubleshoot data action errors in their flows because some types of Architect flows can include null input values in their data action execution requests.

Including a null input value in a data action execution request will typically result in the data action failing during the input schema check, as a “null” type won’t match the schema. This behavior is impossible to experience with the UI test mode as the test requests go through Public API, which removes null values. This has left customers who have tested their data actions in the UI test mode having to troubleshoot difficult action/flow failures due to this difference in behavior.

Change Impact

As the first step of action processing, an execution request with a body like:

{“input1” : null,
“input2” : “ABCD”}

Will be converted to:

{“input2” : “ABCD”}

Date of Change

Mar 15, 2024

Impacted APIs

POST /api/v2/integrations/actions/{actionId}/draft/test
POST /api/v2/integrations/actions/{actionId}/execute
POST /api/v2/integrations/actions/{actionId}/test



Are you sure the UI tester ignores nulls? I'm pretty sure I was able to repro these DA failures via the UI. Unless that was a somewhat recent change. That wouldn't make it into Release Notes, I'm sure.

Hi Paul,

As far as I know there have not been any changes to the UI tester's behavior in a long time. If you can remember / reproduce the issue you were seeing please either DM me with it or create a new thread in the Data Actions room so I can investigate.


Hi Jason,
Is this still on track? I noted that the release date wasn't a Wednesday, and I can still reproduce the issue in the tester user interface.

Note, I'm still using esc.jsonString because it's a best practice for potential freeform data.

This was released globally last week.

The issue that plmcgrn was running into was unrelated to these changes. This change was not intended to change the behavior of the UI tester at all. The purpose was to make all architect flow types behave the same as the UI tester.