This article is for non-technical users configuring UI Policies for Catalog Items in Catalog Builder. It covers the most common mistake we see: two policies controlling the same variable and how to avoid it. It applies to Catalog UI Policies (our focus here) and to classic form UI Policies alike.

 

The scenario

Imagine a catalog item with one multiple-choice variable called Action , offering three choices: Create, Modify, Delete. A variable called Reason should be visible on Create and Modify, and hidden on Delete.

The instinct is to build one policy per choice:

• Action Create — if Action = Create, show Reason
• Action Modify — if Action = Modify, show Reason
• Action Delete — if Action = Delete, hide Reason

This looks reasonable, but it doesn't work reliably. With Reverse if false on, the last policy in Order wins the field's behavior.

When I as a user select Create or Modify from the 'Action' menu, I need to see the Reason field so I can fill it out. However, if I select Delete, the Reason field should disappear.

If you build three separate UI policies to handle this, meaning one telling the form to show the field on Create, one to show it on Modify, and one to hide it on Delete, the form gets confused. Because the 'Reverse if false' setting is active on all of them, the policies constantly fight each other. For example, when I pick Create, the Delete policy sees that the action is not Delete, triggers its reverse rule, and accidentally hides the field on me anyway. The form simply defaults to whatever the very last policy tells it to do.

 

 

Re-ordering only changes which UI Policy has the last word; it can't stop the reversal. This is the root of the "sometimes it works, sometimes it doesn't" behaviour on multi-choice items.

 

The fix: one variable, one policy

From an end user’s perspective, the form behaves smoothly and logically because a single background rule manages the Reason field based entirely on the odd choice out.

When I look at the Action menu, Delete is the unique choice because it is the only one that needs to hide the field. By setting up just one policy that triggers when I choose Delete, the form operates flawlessly:

• When I choose Delete , the rule triggers directly and hides the Reason field as intended.
• When I choose Create , the rule sees that my choice is not Delete. The "Reverse if false" setting kicks in and automatically shows the field to me.
• When I choose Modify , the rule again sees that my choice is not Delete. The "Reverse if false" setting kicks in and shows the field to me here as well.

 

Because there is only one rule controlling the field, there are no competing commands running in the background. The form responds instantly and correctly no matter which option I click.

 

The mental model: count behaviours, not values

A variable only has a handful of behaviours, even when the choice has many values. Reason has exactly two: visible (Create, Modify) and hidden (Delete).

Rule of thumb: one UI Policy should own a variable's behaviour — this scales to any number of variables sharing the same condition. Group choices by what the variable(s) should do, assign one policy on the smaller group, and let Reverse if false do the rest.

 

 

When one policy isn't enough

Some variables genuinely need 3+ behaviours (e.g. hidden on Create, mandatory on Modify, read-only on Delete).

1. Map out every outcome explicitly for each choice.
2. Turn Reverse if false OFF and use mutually-exclusive conditions, so only one policy ever matches.
3. Don't forget to define behaviour for when the field is empty/undefined.

With Reverse if false off, a non-matching policy does nothing — it can't undo another's work. Avoid the middle ground: several Reverse-if-false policies touching the same variable.

 

Checklist before publishing a complex catalog item

• List each variable's distinct behaviours across all choices.
• One behaviour-split? → One policy, assigned on the smaller group, Reverse if false ON.
• Three+ behaviours? → Explicit policies, Reverse if false OFF, mutually-exclusive conditions.
• Never leave two Reverse-if-false policies controlling the same variable.
• Test every choice, including switching between choices mid-form.

 

References

• KB0779159 — "Catalog UI Policies are not being successfully implemented on a catalog item" — Now Support Portal: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0779159