sys_ui_policy Table — ServiceNow Reference

Table Reference/sys_ui_policy

The sys_ui_policy table defines UI Policies that control form field behavior — visibility, mandatory state, and read-only properties — applied by the UI Policy engine in order. Most developers query this table when building form customizations or debugging field behavior issues.

What This Table Is

The sys_ui_policy table stores UI Policy definitions that control form field behavior at runtime. Each record defines conditions and actions that make fields visible/hidden, mandatory/optional, or read-only/writable based on field values and user context.

This table belongs to the Development module and supports ServiceNow's declarative form customization framework. UI Policies execute client-side in the browser, providing immediate field state changes without server round-trips. They're processed in order by the order field value, with lower numbers executing first.

UI Policies don't extend other tables and aren't extended by child tables. They work alongside sys_ui_policy_action records that define the specific field actions to execute when conditions are met. The relationship is one-to-many: one policy can have multiple actions affecting different fields.

Large enterprises typically have 200-500 UI Policy records per major application, with incident and change management forms having the most policies. Performance degrades when more than 20-30 policies apply to a single form, as each policy evaluation adds client-side processing overhead.

When You'll Script Against This Table

Most developers query sys_ui_policy from Script Includes when building form customization tools, or from Background Scripts when auditing form configurations. Business Rules rarely need to touch this table directly since UI Policies handle client-side logic while Business Rules handle server-side logic.

The ui_policy_admin role controls create/update/delete access. Developers with admin can read all policies but need the specific role to modify them. Application-scoped policies respect scope boundaries for cross-scope access.

Common scripting patterns:

Bulk disable policies during data imports to improve performance
Clone policies across similar tables (incident to problem, etc.)
Audit which policies affect specific fields for debugging
Generate documentation of form behavior by table
Reorder policy execution by updating order values
Export/import policy configurations between instances

Table Gotchas

⚠️

UI Policies with no conditions (empty condition field) always evaluate to true and execute every time the form loads or field values change.

⚠️

The order field doesn't automatically renumber when you insert policies between existing ones. You must manually manage order values to control execution sequence.

The table field stores the exact table name, not the label. Extended tables inherit policies from parent tables unless overridden.
Policies execute on list views when applies_to includes 'list', but only affect inline editing scenarios.

⚠️

Policies can conflict with each other. If two policies affect the same field with opposite actions (one sets mandatory, another sets optional), the last one to execute wins.

Performance suffers when policies have complex conditions with OR operators or multiple field references. Keep conditions simple.
The active field only controls whether the policy loads on forms. Inactive policies still appear in Studio and can confuse developers.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

UI Policies work hand-in-hand with sys_ui_policy_action records that define the actual field modifications. Every policy typically has 1-10 associated actions. You'll also frequently query sys_dictionary to understand field types when building policy conditions, and sys_db_object to validate table names in the table field.

When building comprehensive form automation, developers often combine UI Policies with sys_ui_script for client scripts and sys_script for business rules. The sys_ui_section table becomes relevant when policies need to show/hide entire form sections rather than individual fields.

For auditing and compliance reporting, you'll cross-reference sys_update_xml to track policy changes over time, and sys_scope to understand which application owns specific policies in scoped environments.

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

Key Fields

Column	Type	Label	Notes
table	string	Table	The exact table name where this policy applies. Extended tables inherit parent policies unless overridden.
short_description	string	Short description	Human-readable policy name. Critical for maintenance since technical names aren't auto-generated.
active	boolean	Active	Controls whether this policy executes on forms. Inactive policies still appear in Studio lists.
conditions	conditions	Conditions	Encoded condition string that determines when this policy executes. Empty conditions always evaluate to true.
order	integer	Order	Execution sequence number. Lower values execute first. ServiceNow doesn't auto-renumber when inserting policies.
applies_to	choice	Applies to	Controls where policy executes: form views, list views, or both. Default is form views only.
on_load	boolean	On load	Executes policy when form first loads. Essential for initial field state setup.
catalog_item	reference	Catalog Item	Restricts policy to specific catalog item forms. Only applies to sc_req_item and sc_cart_item records.
catalog_category	reference	Catalog Category	Restricts policy to catalog items within a specific category. Broader scope than catalog_item.
view	string	View	Limits policy to specific form view. Empty means all views. Common values: 'default', 'mobile', 'ess'.
inherit	boolean	Inherit	Whether child tables inherit this policy. Only relevant for policies on extended tables.
global	boolean	Global	Legacy field for domain separation. Use sys_domain instead for current domain controls.
reverse_if_false	boolean	Reverse if false	Undoes policy actions when conditions become false. Critical for dynamic form behavior.
script_true	script	Script true	JavaScript executed when conditions evaluate to true. Runs after standard policy actions.
script_false	script	Script false	JavaScript executed when conditions evaluate to false. Only runs if reverse_if_false is true.
sys_scope	reference	Application	Application scope that owns this policy. Affects visibility and modification permissions.

Common Queries

Get all active UI policies for a specific table

// Most basic query - what every developer tries first
var gr = new GlideRecord('sys_ui_policy');
gr.addQuery('table', 'incident');
gr.addQuery('active', true);
gr.orderBy('order'); // Critical for understanding execution sequence
gr.query();

while (gr.next()) {
    gs.info('Policy: ' + gr.short_description + ', Order: ' + gr.order);
    // Process each active policy in execution order
}

Find policies affecting specific catalog items

// Combines choice field filtering with reference lookup
var gr = new GlideRecord('sys_ui_policy');
gr.addQuery('active', true);
gr.addQuery('applies_to', 'form'); // or 'list' or 'both'
gr.addQuery('catalog_item', 'hardware_laptop_sys_id_here');
gr.query();

while (gr.next()) {
    gs.info('Catalog policy: ' + gr.short_description);
    // Found policies specific to this catalog item
}

Audit which policies execute on form load across all tables

// Real-world scenario for performance troubleshooting
var gr = new GlideRecord('sys_ui_policy');
gr.addQuery('active', true);
gr.addQuery('on_load', true);
gr.addQuery('applies_to', 'IN', 'form,both');
gr.orderBy('table');
gr.orderBy('order');
gr.query();

var tableCount = {};
while (gr.next()) {
    tableCount[gr.table] = (tableCount[gr.table] || 0) + 1;
}
// Identify tables with too many on-load policies

Count active policies by application scope

// Aggregate count using GlideAggregate
var ga = new GlideAggregate('sys_ui_policy');
ga.addQuery('active', true);
ga.groupBy('sys_scope');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var scopeName = ga.sys_scope.getDisplayValue();
    var count = ga.getAggregate('COUNT');
    gs.info('Application: ' + scopeName + ', Active Policies: ' + count);
}

Wrong way vs right way to find policies with complex conditions

// WRONG: This query won't find encoded condition strings
// var wrong = new GlideRecord('sys_ui_policy');
// wrong.addQuery('conditions', 'CONTAINS', 'state=6');

// RIGHT: Conditions are encoded, search description instead
var gr = new GlideRecord('sys_ui_policy');
gr.addQuery('active', true);
gr.addQuery('table', 'incident');
gr.query();

while (gr.next()) {
    // Use GlideFilter to properly evaluate condition strings
    if (gr.conditions.toString().indexOf('state') > -1) {
        gs.info('Found state-dependent policy: ' + gr.short_description);
    }
}

Related Tables

sys_dictionary sys_db_object sys_script

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