Hide Catalog Variables with Value "False" in Approval Record

[Subalakshmi P2]

Hi Team,

Is there an OOB way to hide catalog variables with a value of false from the approval record? Blank variables are already hidden, but Boolean variables showing false are still displayed.

This requirement applies only to specific catalog items. Has anyone implemented a solution for this?

Thanks.

[Subalakshmi P2]

Hi,

Thanks for your response.

These variables need to remain visible under certain conditions. We have multiple optional approval levels, and the corresponding "Require approval from all approvers (if more than one)" field should only be displayed when the related approver field is populated.

For example, if Level 2 Approver is selected, only then should the corresponding approval option be shown. 

I was able to hide the field on the RITM form using UI policies. Below is the screenshot from RITM. However, the field is still displayed on the approval record even when the corresponding approver field is not populated.

Could you advise on the best way to achieve this?

[drbob]

We came across this too - we had some complex catalog items and often the submitted fields were a small fraction of the active variables. Most times the fields hidden on the catalog item were blank so didn't really mess up the approval mail's content (variable name was listed but no data). ...but true/false it hard to get around.

I don't think there's any OOTB way to handle this and even coding it is hard (you really need to have something note the fields visible at submission and use that list to decide what to put in the mail).

Probably the only way to do it for more complex catalog items is for them to have their own mail template and somehow (we didn't get as far as doing this so I can't say for sure how/where) have the approval mail use a different template for that catalog item.

[drbob]

The (well, one of at least) OOTB function is "getRequestItemVariables" in the "RequestNotificationUtilSNC" Script Include - which adds non-empty variables...

            if (variables.get(i).getLabel() !== '' && variables.get(i).getDisplayValue() && variables.get(i).getDisplayValue() !== '' && variables.get(i).isVisibleSummary()) {

                var displayVal = variables.get(i).getDisplayValue();

                ...

                }

Interestingly that _does_ call "isVisibleSummary()" - I don't know what that does but it sounds like the thing I alluded to (a record of what is seen on the form). Whether it's at the point of submission or not I'm not sure. It would need more digging. Also may depend on how fields are hidden (Catalog UI Policy actions vs Catalog UI Policy Script vs Catalog Client Script) and the other how (hide vs visible - hopefully they are treated the same).

There's more digging required to understand this fully but to the original point, that script continuers by doing an adjustment specifically for "string" types (switched line breaks to HTML breaks) it would be easy to add, in a customized copy, something that skipped adding "False" valued True/False to the list. ...but you'd still need to track down how to divert to that version of the script for specific catalog items - I'm sure there would be plenty where it's important to show a T/F with "False" value.

[ajmalmuhamm]

Hi @Subalakshmi P2 ,

OOTB, ServiceNow generally treats a Boolean variable with a value of false as an actual value, so it is not handled the same way as a blank variable. That's why it can still appear in the approval variable summary.

If you need this only for specific catalog items, I would avoid changing the global approval widget/formatter.

A cleaner approach would be to handle it at the catalog-item level, for example by using a Catalog UI Policy/Client Script to avoid populating unnecessary Boolean variables, where possible.

If the variable must remain false, then you would typically need to customize the component that renders the approval variables (for example, the approval widget/formatter) so that it ignores Boolean variables whose value is false. Make sure to clone the OOB component rather than modifying it directly.

Before customizing, I would also check your ServiceNow release because the approval experience differs between Core UI, Service Portal, and Workspace, and some versions have different OOB options for displaying catalog variables.