Flow Designer Get Catalog Variables - Yes/No type output value in Zurich

[Alex Aluchi]

Hello - we have this Zurich issue and would apreciate your input.

In Zurich release we observed that Service Catalog type Yes/No variables when leveraged with Flow Designer > Get Catalog Variables action output Runtime Value true/false as opposed to yes/no in Yokohama or Xanadu releases (added some screen shots for context)

Are you aware of some system property that mitigates this issue? Any feedback is appreciated. Thanks all.

 

 

 

[Dr Atul G- LNG]

Also, try repairing or upgrading the Flow Designer plugin once to see if that resolves the issue.

[Alex Aluchi · Accepted solution]

@Ankur Bawiskar @Dr Atul G- LNG @kaushal_snow ServiceNow answered to the HI Case and they do have a property that will revert behaviour. 
Add system property "com.glide.hub.flow.catalog_variables.yes_no_as_boolean" and set value to false.

[Ankur Bawiskar]

@Alex Aluchi 

So it's a bug.

Which developer would want a Yes/No value to be converted to True/False after upgrade.

It's good that they provided the solution.

[BorisR112699856]

Big thanks Alex for posting your solution to this. I was totally scratching my head and found your post.
Wondering if you stumbled over any other impact with creating this property. I dont see any impact since its only the variables that are the problem and this solves for it. I am also wondering whether ServiceNow has officially mentioned it somewhere. Those items are very time consuming to figure out.

[Alex Aluchi]

Hi Boris, well we ended up not using the property because we had products like HRSD where ServiceNow already refactored the OOB flows to use the new variable behaviour so thread lightly. If it's affecting production and you don't have any dependent features like HRSD that would break than you can use it temporarily and meanwhile refactor the flows so you can adapt to the new way.
What we did is we created a small utility function in a Script Include and we use that to leverage these types of fields in flows and the script include works based on an attribute that determines the output (whatever we need, true/false, yes/no) and leverages both inputs yes/no or true/false. We did this so even if the property is ever used or not we don't have issues.
Bottom line I would use the SN property to move back to yes/no only temporary if needed, otherwise long term it might be a headache with OOB flows. Hope it helps