Migrated Yokohama -> Australia: The yes_no_as_boolean property is a trap for Custom Actions & Cart APIs
Hey everyone,
We just went through a major multi-release migration, jumping from Yokohama all the way to the Australia release, and we’ve run face-first into an architectural nightmare regarding Yes/No Catalog Variables.
As many of you know, ServiceNow modernized the Flow Designer engine a couple of releases back (around Zurich) so that Yes/No variables natively evaluate as true JavaScript Booleans (true/false) rather than their historical strings ("Yes"/"No").
To mitigate this during our upgrade, we deployed the documented system property:com.glide.hub.flow.catalog_variables.yes_no_as_boolean = false
The Trap:
This property looks like it works at first glance. It successfully forces native Flow Designer data pills (like from Get Catalog Variables) and standard out-of-the-box IF conditions to continue returning and evaluating the legacy strings ("Yes"/"No").
But here is where the property completely abandons you:
1. Flow Designer Custom Actions (Script Steps): When a data pill is passed into a Custom Action input, the runtime engine seemingly ignores the system property. The data enters the JavaScript step as a literal primitive Boolean true or false. Any legacy code checking if (inputs.variable == 'Yes') fails silently because it receives a boolean instead of a string.
2. "Submit Catalog Item Request" Action (Cart APIs): When using flows to dynamically submit other catalog items, the underlying Cart API layer strictly validates incoming payloads. It expects Booleans, ignoring the property entirely. Passing a legacy "Yes" string results in dropped data or payload errors because it's pushing a text string into an endpoint that strictly expects a Boolean.
The Problem:
While we know we can fix this via inline scripting f(x) on action inputs and updating the JavaScript inside custom actions to look for (inputs.variable == 'Yes' || inputs.variable === true), doing this manually across instances introduces massive regression testing risks and heavy manual refactoring.
Has anyone solved this?
If you migrated a footprint from Yokohama/Washington to Zurich/Australia:
• Is there another hidden, global system property that actually forces compliance across all execution layers (including Custom Action script steps and Cart APIs)?
• If no property exists, how did you handle updating these touchpoints? Did you write a fix script to mass-update flow definitions/inputs, or did you honestly have to bite the bullet and manually refactor every single script and mapping touchpoint?