What is the difference between a Client Script and a UI Policy?

The Real Question

Both Client Scripts and UI Policies run on the client side (in the browser) and both manipulate the form. The confusion is real — interviewers want to hear you explain the clear boundary between declarative and scripted approaches.

UI Policy (No-Code / Declarative)

A UI Policy uses conditions configured through the UI to control field behavior — no code required.

• What it can do: Make a field mandatory, make it read-only, show/hide a field.
• How it works: You set a condition (e.g., 'Priority is Critical') and define actions (e.g., 'Set Assignment Group to Mandatory'). All configured via dropdowns — no JavaScript.
• Best for: Simple, condition-based field behaviors that admins (non-developers) can manage.

Client Script (Code / Imperative)

A Client Script uses JavaScript to react to form events — much more flexible but requires coding knowledge.

• Types: onLoad (form opens), onChange (field value changes), onSubmit (form is submitted), onCellEdit (list editing).
• What it can do: Everything a UI Policy does, PLUS: show alerts, make API calls (GlideAjax), set field values dynamically, perform complex calculations, interact with multiple fields at once.

// UI Policy equivalent in Client Script:
// 'When Priority is Critical, make Assignment Group mandatory'
function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading) return;
  if (newValue == '1') { // Priority = Critical
    g_form.setMandatory('assignment_group', true);
  } else {
    g_form.setMandatory('assignment_group', false);
  }
}

Decision Guide

• Need to make a field mandatory/read-only/visible based on a simple condition? → UI Policy
• Need to set a field's value based on another field? → Client Script (onChange)
• Need to call the server for data? → Client Script + GlideAjax
• Need to validate before the form saves? → Client Script (onSubmit)
• Need non-developers to maintain the rule? → UI Policy

Important Gotcha

If both a UI Policy and a Client Script control the same field, the UI Policy wins because it runs after the Client Script. This is a common source of bugs — one developer sets a field with a Client Script, another admin creates a UI Policy that overrides it, and neither understands why their change 'doesn't work.'