UI Policies vs UI Actions: Which to Choose?

Introduction

ServiceNow gives you two powerful tools for controlling form behavior: UI Policies and UI Actions. Many newcomers confuse them or use the wrong one for a given task. This guide clarifies what each tool does, when each should be used, and provides real patterns for common form requirements.

---

UI Policies: Controlling Field Behavior

A UI Policy dynamically controls field visibility, mandatory status, and read-only status based on conditions. It fires client-side, in real time, as the user changes form values.

What UI Policies Control

Property	Effect
Visible	Show or hide a field
Mandatory	Make a field required or optional
Read Only	Make a field editable or locked

UI Policy vs. Client Script for Field Control

You can accomplish the same field manipulation with a Client Script's onChange. So when do you use each?

Use UI Policy when:

• The condition is simple (based on one or a few field values)
• You don't need custom JavaScript logic
• You want non-developers to be able to read/maintain the rule
• The rule needs to apply on both form load AND field change (UI Policies do both automatically)

Use Client Script when:

• The condition requires complex logic, loops, or GlideAjax calls
• You need side effects beyond visibility/mandatory/read-only
• You need precise control over exactly when the logic fires

Creating an Effective UI Policy

Scenario: When an incident's Category is "Network", show the "Network Device" field and make it mandatory.

1. Navigate to System UI > UI Policies
2. Set Table: Incident [incident]
3. Short Description: Show Network Device when Category = Network
4. Conditions: Category | is | Network
5. Enable On Load checkbox (applies rule when form first opens)
6. Add UI Policy Action:
   • Field: network_device
   • Visible: True
   • Mandatory: True

Critical: Always define what happens when the condition is FALSE (the "reverse" state). If Category is NOT Network, should network_device be hidden again? Set the reverse action explicitly.

UI Policy Ordering

When multiple UI Policies affect the same field, Order determines which wins. Lower order numbers run first. The last policy to set a property wins.

Order 100: If Priority = 1, make Assignment Group mandatory
Order 200: If State = Closed, make all fields read-only

In this example, if a P1 incident is Closed, the "read-only" policy (Order 200) wins for Assignment Group.

---

UI Actions: Adding Buttons and Context Menu Items

A UI Action adds a button, context menu item, or link to a form or list. It runs JavaScript (client-side, server-side, or both) when clicked.

UI Action Types

Type	Where It Appears
Form Button	Button bar at top of form
Form Context Menu	Right-click menu on form
Form Link	Link at bottom of form
List Button	Button bar on list view
List Context Menu	Right-click menu on list
List Choice	Action choice in list

Client-Side vs. Server-Side UI Actions

Client-side only (script runs in browser):

// Validate before submit
if (g_form.getValue('priority') == '') {
    alert('Please set a priority before escalating.');
    return false; // Prevent action from proceeding
}
// Navigate to a related form
var url = '/nav_to.do?uri=incident.do?sys_id=' + g_form.getUniqueValue();
window.open(url, '_blank');

Server-side only (runs Rhino JavaScript on server):

// Create a related Problem record from an Incident
var problem = new GlideRecord('problem');
problem.initialize();
problem.setValue('short_description', 
    'Problem raised from ' + current.getValue('number'));
problem.setValue('description', current.getValue('description'));
problem.setValue('assignment_group', current.getValue('assignment_group'));
var probSysId = problem.insert();
current.setValue('problem_id', probSysId);
current.update();
action.setRedirectURL(current);

Both client and server (client validates, server executes):

// Client script (runs first)
if (!confirm('Are you sure you want to escalate to P1?')) {
    return false; // Cancel server execution
}

// Server script (runs after client confirms)
current.setValue('priority', '1');
current.setValue('escalated', 'true');
current.update();
gs.addInfoMessage('Incident escalated to P1 successfully.');

Condition Field in UI Actions

Use the Condition field to control visibility of a UI Action based on record state:

// Show "Escalate to P1" button only when priority is 2, 3, or 4
current.priority != 1 && current.state != 6 && current.state != 7

This prevents clutter by hiding buttons that don't apply to the current record state.

---

Side-by-Side Comparison

Feature	UI Policy	UI Action
Purpose	Control field properties	Add buttons/menu items
Execution	Client-side (automatic)	On user click
Can modify field visibility	✅	Via g_form in client script
Can submit/save record	❌	✅
Can run server logic	❌	✅
Fires on field change	✅	❌ (only on click)
Non-developer friendly	✅	Partially

---

Common Patterns

Pattern 1: Progressive Disclosure (UI Policy)

Hide advanced fields by default. Reveal them only when the user selects a specific category or type. Keeps forms clean for simple cases.

Pattern 2: Approval Shortcut (UI Action)

Add a single "Approve" button that sets State = Approved, sets Approved By = current user, and sends a notification — all in one click instead of three separate form edits.

Pattern 3: Guided Resolution (UI Policy + UI Action)

1. UI Policy makes "Resolution Notes" mandatory when State is set to Resolved
2. UI Action "Resolve Incident" button validates notes are filled, then sets state to Resolved and triggers SLA stop

---

Best Practices

• Always define the "reverse" condition in UI Policies
• Use Conditions on UI Actions to hide irrelevant buttons
• Keep client scripts in UI Actions minimal — move heavy logic server-side
• Use action.setRedirectURL(current) to stay on the form after server execution
• Add gs.addInfoMessage() or gs.addErrorMessage() to server UI Actions for user feedback
• Test UI Policies with both onLoad and onChange scenarios

---

Conclusion

UI Policies own form field behavior — use them to guide users by showing the right fields at the right time. UI Actions own user-triggered operations — use them to encapsulate multi-step processes into a single, auditable click. Together, they transform raw data forms into intuitive, workflow-aware interfaces.