Service Catalog

Configure a Catalog UI Policy

Catalog item forms need to react to user inputs — show different variables based on what someone selects, make fields mandatory only when relevant. This guide shows you how to build catalog UI policies that control variable visibility and requirements dynamically.

Why static catalog forms break down

Static catalog item forms force users through irrelevant fields and create confusing request experiences. A server request form that shows storage options when someone picks 'virtual machine' wastes time and creates bad data. Without dynamic forms, catalog managers either build separate items for every scenario (maintenance nightmare) or accept that users will submit incomplete or wrong information. The people building these catalogs — service owners and catalog admins — end up fielding clarification calls that could have been prevented.

How catalog UI policies work

A catalog UI policy is client-side logic that shows, hides, or makes variables mandatory based on other variable values. Unlike form UI policies that work on database fields, catalog UI policies target catalog variables by their variable name (not the label users see). You set up conditions based on variable values, then define actions that affect other variables. The policy evaluates in real-time as users interact with the form. Start with simple show/hide logic, then add mandatory requirements and more complex conditions as needed.

Building sophisticated catalog experiences

Once basic policies work, you can chain multiple policies together, use reference variable values in conditions, and combine policies with catalog client scripts for advanced interactions. Production-quality implementations organize policies logically, use consistent naming conventions, and document complex conditional logic. The best catalog experiences feel intuitive because users only see relevant options and can't submit incomplete requests.

Before you start

  • catalog_admin or admin role
  • Existing catalog item with variables configured
Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Step by step

1

Navigate to Catalog UI Policies

Go to Service Catalog > Catalog Definitions > Catalog UI Policies. Click New to create a new policy. You'll see this is similar to form UI policies but scoped specifically to catalog items.

TIP

Catalog UI policies only appear in this module — they don't show up in the regular UI Policies list.

2

Configure the policy basics

Set the Catalog Item to your target item using the reference picker. Give it a descriptive Name like 'Show storage options for VMs'. Set Active to true and leave Reverse if false to start with — most policies use the default forward logic. Order determines execution sequence when multiple policies apply to the same item.

TIP

Start with Order 100 so you can insert policies with 50, 150, etc. later without renumbering everything.

3

Build the condition logic

In the Conditions tab, click Edit to open the condition builder. Create conditions using variable names, not labels — if your variable label is 'Server Type' but the variable name is 'server_type', use 'server_type' in conditions. Set up your logic like 'server_type is virtual_machine'. You can combine multiple conditions with AND/OR operators.

TIP

Check the variable name in the catalog item's variables list — the Name field, not Display name, is what you use here.

4

Define the UI Policy Actions

Click the UI Policy Actions tab, then New. Set Type to Show, Hide, or Mandatory based on what you want to happen. In the Variable field, enter the variable name (again, not the label) that you want to affect. For show/hide actions, set Visible to true or false. For mandatory actions, set Mandatory to true and the policy will require the field when conditions match.

5

Test the policy behavior

Save the policy and open your catalog item from the service catalog (not the form designer). Change the variable that triggers your condition and verify the target variables show, hide, or become mandatory as expected. Test edge cases like clearing values and switching between different options that trigger different policies.

Best practices

  • Always use variable names in conditions and actions, never variable labels — labels can change but names are consistent references.

  • Create separate UI policies for different logical behaviors instead of cramming multiple unrelated actions into one policy.

  • Test policies from the actual catalog interface, not the form designer — client-side behavior only works in the real user experience.

  • Use clear, descriptive names that explain both the condition and the action — 'Hide storage for virtual servers' is better than 'Server policy 1'.

  • Order policies thoughtfully when they interact — a policy that hides a variable should run before one that makes the same variable mandatory.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue