UI Policies & UI Actions

UI Policy Overview

A UI Policy is a no-code mechanism for dynamically controlling field behavior on a ServiceNow form. Rather than writing JavaScript, administrators define rules that automatically make fields mandatory, read-only, or hidden based on conditions evaluated in the browser.

Key Characteristics

UI Policy Anatomy

Every UI Policy record has a set of header fields that define when and how it activates, plus a related list of UI Policy Actions that specify what happens to individual fields.

Policy-Level Fields

UI Policy Actions — Field-Level Control

A UI Policy header defines the when and where. UI Policy Actions define the what — specifically, what changes to apply to individual fields when the policy condition is met.

Action Structure

Each UI Policy Action targets one field and independently controls three behavioral properties for that field:

Storage & Navigation

• Actions are stored in the sys_ui_policy_action table
• They appear as a related list at the bottom of each UI Policy record
• You can add multiple actions to one policy — one row per field you want to control
• A single policy can control many fields simultaneously

Practical Example

UI Policy vs. Client Script (High-Frequency Exam Topic)

Both UI Policies and Client Scripts run client-side in the browser. The exam frequently tests when to use each — understanding the trade-offs is critical.

Client Script g_form Equivalents

When you need UI Policy-style behavior inside a Client Script, use these g_form API methods:

// Make a field mandatory (true = mandatory, false = optional)
g_form.setMandatory('short_description', true);

// Make a field read-only (true = locked, false = editable)
g_form.setReadOnly('impact', true);

// Show or hide a field (true = visible, false = hidden)
g_form.setVisible('resolution_notes', false);

// Set a field's value (cannot be done with UI Policy alone)
g_form.setValue('state', '6'); // Sets State to Resolved

// Combined example: onLoad Client Script
function onLoad() {
  var priority = g_form.getValue('priority');
  if (priority == '1') {
    g_form.setMandatory('short_description', true);
    g_form.setReadOnly('impact', true);
  }
}

UI Policy vs. ACL — The Layer Boundary

This is perhaps the most important conceptual distinction on the entire CSA exam. UI Policies and ACLs can both make fields read-only or invisible, but they operate at fundamentally different layers with very different security implications.

UI Actions

UI Actions are configurable buttons, links, and context menu items that appear on forms and lists. They allow administrators and developers to expose custom functionality — from simple form saves to complex server-side workflows — as clickable elements in the ServiceNow UI.

Key Facts

• Stored in the sys_ui_action table
• Navigate via System UI > UI Actions or type sys_ui_action.list
• Can run client-side JavaScript (browser) or server-side scripts (GlideRecord)
• Appear on both forms (individual record views) and lists (table row views)
• A Condition field controls when the action is visible to the user
• An Action name provides a unique identifier used in scripts and ACLs

UI Action Types

UI Action Fields

Client vs. Server UI Actions & Common Patterns

UI Actions can execute code either in the browser (client) or on the server. Understanding when each runs and how they interact is a key exam topic.

Client UI Action

• The Client checkbox is checked on the UI Action record
• Script runs as JavaScript in the user's browser
• Has access to g_form, g_user, g_list, window, DOM APIs
• Can call g_form.submit() to trigger a server-side save after client validation
• Cannot directly access GlideRecord — must use GlideAjax for server data lookups
• Useful for: validation before save, setting field values, user confirmation dialogs, navigation

Server UI Action

• The Client checkbox is unchecked — script runs on the server
• Has access to current (the active record), gs (GlideSystem), GlideRecord
• Used for: updating records, calling web services, running business logic, setting state
• Can use action.setRedirectURL() to navigate the user after execution

Common UI Action Patterns

Server UI Action Script Pattern

// Server-side UI Action — "Resolve Incident"
// Table: incident | Client checkbox: UNCHECKED
current.state = '6';           // Resolved
current.close_code = 'Solved'; // Resolution code
current.resolved_by = gs.getUserID();
current.resolved_at = new GlideDateTime();
current.update();

// Redirect user to the incident list after resolution
action.setRedirectURL('incident_list.do');

// Client-side UI Action — validate before save
// Table: incident | Client checkbox: CHECKED
if (!g_form.getValue('short_description')) {
  alert('Short Description is required before saving.');
  return; // Stop — do not submit
}
g_form.submit(); // Proceed with save

Key Exam Facts & Traps

This section consolidates the highest-priority facts and the most common wrong-answer traps for UI Policies and UI Actions on the CSA exam.

Quick Reference Summary