ServiceNow UI Policies

UI Policies control how form fields look and behave based on conditions — making fields visible, mandatory, or read-only without writing a single line of JavaScript. For many common field behavior requirements, UI Policies replace Client Scripts entirely, delivering the same outcome through a simple no-code configuration interface.

UI Policies vs. Client Scripts

                    UI POLICY          CLIENT SCRIPT
Requires scripting:    No                  Yes
Best for:           Simple conditions   Complex logic
Changes fields:     Yes (V/M/R)        Yes (full g_form API)
Runs on:            Form load/change   Form load/change
Maintenance:        Easier             More technical
Performance:        Slightly better    Depends on script size

V = Visible, M = Mandatory, R = Read-only

What a UI Policy Does

A UI Policy applies three possible changes to fields when a condition is met:

• Visible: Show or hide the field
• Mandatory: Make the field required or optional
• Read-only: Prevent or allow editing of the field

Each UI Policy can affect multiple fields simultaneously. One policy that fires when State = Resolved can make "Resolution Notes" visible, mandatory, and editable — all at once.

Creating a UI Policy

Navigate to System UI > UI Policies and click New. Fill in these configuration sections:

1. Conditions Section

Define when the policy applies. Use the condition builder to specify field values that trigger the policy. For example: State = Resolved (6). When this condition becomes true on the form, the policy fires.

2. UI Policy Actions Section

At the bottom of the UI Policy form, a related list shows UI Policy Actions. Each action row targets one specific field and sets its Visible, Mandatory, and Read-only states to True, False, or Leave Alone. "Leave Alone" means the policy does not change that attribute — other rules or defaults still apply.

UI Policy: "Require Resolution Notes When Resolved"
──────────────────────────────────────────────────────────
Condition:  State = 6 (Resolved)
Short-circuits: true (reverse actions when condition is false)

UI Policy Actions:
─────────────────────────────────────────────────────────
Field              │ Mandatory │ Visible │ Read-only
─────────────────────────────────────────────────────────
close_notes        │ True      │ True    │ False
close_code         │ True      │ True    │ False
resolution_date    │ Leave     │ True    │ True (auto-set)
─────────────────────────────────────────────────────────

Reverse Actions

The "Reverse if false" option (also called short-circuits) automatically reverses the UI Policy actions when the condition becomes false. If the user changes State from Resolved back to In Progress, the policy automatically makes Resolution Notes non-mandatory and hides it again. Without reverse actions, the administrator would need to create a second UI Policy to undo the first one's effects manually.

Practical UI Policy Scenarios

Scenario 1: Category-Based Fields

Show a "Hardware Serial Number" field only when Category = Hardware. When the user selects Hardware, the field appears and becomes mandatory. When the user selects any other category, the field hides and becomes optional.

Scenario 2: Lock Fields After Closure

Make all incident fields read-only when State = Closed. This prevents anyone from editing a closed incident's core data while still allowing it to be viewed.

UI Policy: "Lock Closed Incidents"
Condition: State = 7 (Closed)

UI Policy Actions:
All key fields → Read-only = True

Scenario 3: Approval Required Fields

A change request form shows risk assessment fields only when the change type is Normal or Emergency. Standard changes skip the risk assessment section entirely since they are pre-approved.

Run Scripts: Advanced UI Policy Actions

UI Policies optionally execute a script when the condition fires. This hybrid approach handles most scenarios without writing a full Client Script — the condition logic stays in the UI Policy, and only a small script block handles edge cases the condition builder cannot express.

Order of Execution: UI Policies and Client Scripts

When both UI Policies and Client Scripts are active on the same form, they can conflict — one makes a field mandatory while another makes it optional. ServiceNow applies UI Policy actions after Client Scripts. If a UI Policy marks a field as mandatory and a Client Script tries to make it optional, the UI Policy wins. Administrators document which tool controls each field to prevent conflicts.

UI Policies in the Service Catalog

Catalog UI Policies work identically to standard UI Policies but apply to catalog item variable sets. When an employee fills out a service catalog request form, Catalog UI Policies show or hide variable questions dynamically — guiding the employee through only the fields relevant to their specific selection without cluttering the form with irrelevant options.