Catalog UI Policy vs Variable Set UI Policy Precedence issue resolved in London release

Hello guys and girls!

Recently, I was working on a catalog item. My goal was to hide a Variable belonging to a Variable Set. As per the best practices, I used a Catalog UI Policy to hide the variable. However, a UI Policy in the Variable Set set the very same Variable’s Visibility to true. After exploring various options, I learned that the UI Policy in the Variable Set always take precedence over the Catalog UI Policy.

Confused???? Let’s look at an example….

I created a catalog item with the name Pen and Paper. The aim is to show variables Paper and Pencil and make them mandatory. I must hide the variable Pen in the variable set Stationery. I have another variable called Pen (not in VS) that I need to hide. Our form must look like this….

However, our form looks like this… :(

Service Portal (left) and Desktop View (right)

The catalog item is configured as shown below.

Catalog Item
Variables in Variable set Stationery (left) and Variable belonging to the Catalog Item (right)
Catalog UI Policy
UI Policy in Variable Set

The issue at hand is that the UI Policy in the variable set takes precedence over the Catalog UI Policy.

I tried to solve this problem by changing the order of the UI Policies. Unfortunately, it did not work. I tried something provided on one of the Hi Service Pages.

Go to System Properties → Service Catalog.

Find the option Enable the UI Policies related to Variable Set to be run first.

I used both the options for the Service Catalog Setting. Nothing worked. Too bad??? Yeah. Here’s what ServiceNow says: https://hi.service-now.com/kb_view.do?sysparm_article=KB0551679

Cause

The UI Policy that ran last will take precedence. A Variable Sets UI Policy, regardless of the value of the Order field, will never take precedence over any Catalog Item UI Policy.

Resolution

Review the design of your solution and ensure that the UI Policies that you want to take precedence run after any conflicting UI Policies.

OKAY NOW! Here’s the (temporary) SOLUTION for Jakarta and Kingston:

At this point, I stepped in and simply removed the UI Policy in the variable set and wrote an equivalent Client Script. I know!! It’s not the best practice but I need the form to run. According to the golden rule, UI Policies always take precedence over Client Scripts. And so, the issue was resolved (phewwww). Oh no, but not completely. Creating too many customizations (too many scripts!) can make migrations and instance updates a real nuisance.

**UPDATE**

I simulated the same scenario in London release. The issue has been resolved for both desktop and mobile views. Good job ServiceNow!! :)

Venkata Siva Abhishek Munukutla

Written by

|| Grad Student at ASU || Majoring in Information Technology || Passionate about ServiceNow ||

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade