Data policies & UI policies in Administration

Enforce field rules, on the form and everywhere else.

Both UI policies and data policies control whether fields are mandatory, read-only or visible, but they act in different places, run at different points in a record's lifecycle, and answer to different rules of precedence. Choosing the right one (and understanding how it interacts with client scripts, ACLs and dictionary defaults) is one of the everyday judgement calls a ServiceNow admin makes. This lesson goes through both mechanisms in depth.

THE ONE-LINE DISTINCTION

A UI policy is a client-side rule that reacts as the user fills in a form. A data policy is a server-side rule enforced whenever a record is written, no matter the channel, form, import, API, or script.

UI policies

A UI policy (sys_ui_policy) runs in the browser, on a form, in response to a condition you define. When the condition is true it applies a set of UI Policy Actions to named fields, and optionally runs a script. All of this happens client-side, without you writing a client script by hand, which is exactly why UI policies are preferred over onChange scripts for simple mandatory/read-only/visible behaviour.

Each UI policy has three moving parts:

Condition, a condition builder expression (e.g. Priority is 1 - Critical). While a form is open the condition is re-evaluated every time a relevant field changes.
UI Policy Actions, one row per field, each setting Mandatory, Read only and Visible to True, False or Leave alone. Leave alone means "don't touch this attribute", critical for letting multiple policies co-operate.
Scripts, optional Execute if true / Execute if false client scripts for logic the actions can't express.

Two checkboxes govern when a UI policy fires:

Reverse if false, when the condition becomes false again, undo the actions (revert fields to their previous state). Leave this on unless you deliberately want a one-way change.
On load, evaluate the policy immediately when the form opens, not only after a field changes. Turn this off for policies that should only react to user edits.

Order matters. UI policies have an Order field and run low-to-high; UI policies run after client scripts of the same trigger, and a later policy's True/False action will override an earlier one, which is why Leave alone exists. A UI policy can also be scoped to a view and to Global vs a specific table via Inherits, so a policy on task can cascade to incident, problem and change.

WORKED EXAMPLE · UI POLICY

Goal: when an incident's State is set to Resolved, make Resolution code and Resolution notes mandatory on the form.

Table incident · Condition State is Resolved
Action 1 Resolution code → Mandatory: True, Visible: Leave alone
Action 2 Resolution notes → Mandatory: True
Reverse if false on, so the requirement lifts if the agent moves State back to In Progress.

Data policies

A data policy (sys_data_policy2) enforces the same mandatory / read-only rules, but at the data layer. It runs on the server whenever a record on that table is inserted or updated, so it holds regardless of how the record arrived: a form submission, an Import Set load, an inbound REST/SOAP call, or a GlideRecord script. This is the mechanism you use to guarantee data quality across every channel, a form-only rule is trivially bypassed by an import.

Data policies support the same three attributes through Data Policy Rules: Mandatory and Read only per field (there is no "visible" at the data layer, visibility is purely a form concept). A field that a data policy marks read-only cannot be changed by any write, which is a stronger guarantee than a UI policy's read-only field.

Two settings decide the reach of a data policy:

Apply to imports, enforce the rule during Import Set transforms. Off by default, and one of the most common oversights: a "mandatory" data policy that quietly lets bad import rows through because this box was never ticked.
Use as UI policy on the client, mirror the data policy onto the form as well, so users get immediate client-side feedback in addition to server enforcement. This gives you one rule that covers both worlds.

Here is exactly why the channel matters. Say Short description is required. A UI policy stops a user submitting the empty form, but a background script writes straight to the table and never sees that policy:

var gr = new GlideRecord('incident');
gr.initialize();
gr.priority = 1;
gr.insert();  // no short_description, a UI policy can't stop this

With only a UI policy in place, that insert succeeds and a junk record lands in the table.

Add a data policy that marks Short description mandatory, and the same insert() is rejected server-side, it returns null and logs:

Data Policy Exception: 'Short description' is mandatory

How the two relate, and converting between them

Because they share the same field attributes, ServiceNow lets you convert between the two. From a UI policy you can generate an equivalent data policy (and vice versa) using the related links / conversion action, so a rule that started life on the form can be promoted to data-layer enforcement without rebuilding it. The typical mature pattern is a single data policy with "Use as UI policy on the client" enabled: server-side integrity plus form-side UX from one record.

Step by step: create a data policy

In the Application Navigator go to System Policy › Rules › Data Policies and click New.

Set Table (e.g. incident) and a Conditions filter, leave it blank to apply to every record.

Tick Apply to imports and, if you want form feedback too, Use as UI policy on the client.

Save, then add Data Policy Rules in the related list, one per field, setting Mandatory or Read only to true.

Test both paths: submit the form empty, then run an import row missing the field. Both should be blocked.

UI policy

Data policy

Runs where

Browser, on a form

Server, on every write

Covers imports / API

Yes (with "Apply to imports")

Attributes

Mandatory, Read-only, Visible

Mandatory, Read-only

Can run scripts

Yes (client scripts)

Where policies sit among the other rules

Mandatory/read-only can also come from the dictionary (a field marked mandatory in sys_dictionary), from ACLs (write access), and from client scripts using g_form.setMandatory() etc. When several of these disagree, the practical precedence on a form is: dictionary default → UI policy / data-policy-as-UI → client scripts running later can override, but ACLs are the ultimate authority, no policy can make a field editable that the user has no write ACL for. For genuine integrity, put the rule at the data layer; use the form-side layers for guidance and UX, not as your security boundary.

Go deeper

Optional deep-dives, expand the ones you need.

The full order of execution

On a form submit the client side runs first, UI policies and onSubmit client scripts, then the server takes over in this order:

Data policies evaluate as part of the field validation before the write.
before business rules run, then the database insert/update.
after and async business rules run once the record is committed.

Because data policies sit ahead of the write, a failed rule stops the record before any before-rule side effects fire, cleaner than validating inside a business rule.

Policy vs. business rule vs. dictionary

Dictionary mandatory, always required, everywhere, unconditionally. Use only when the field is genuinely never optional.
Data policy, conditional mandatory/read-only across all channels, no code. The default choice for integrity.
Business rule, when you need logic beyond simple field states: cross-record checks, calculated values, aborting with current.setAbortAction(true).

Rule of thumb: reach for the least powerful tool that does the job. Dictionary < data policy < business rule.

Debugging: why isn't my policy firing?

Is Active checked, and does the Condition actually match the record? Test the filter as a list query.
UI policy not reacting on open? Turn on On load. Not reverting? Turn on Reverse if false.
Data policy skipping imports? You forgot Apply to imports.
Two policies fighting? One is using True/False where it should use Leave alone; check the Order values.
Field still editable? An ACL or a later client script is overriding, ACLs win.

Scoped apps & policies

Policies live in an application scope like any other record. A data policy in a scoped app can enforce rules on tables that app owns; to add one to a table from another scope you need the target application's cross-scope settings to allow it. Keep policies in the same scope as the table they protect, and capture them in an update set (in the global scope) or the app's version so they move cleanly between instances.

When to reach for each

Dynamic form behaviour only, show a field when Category is "Hardware", make Assignment group mandatory when State is "Assigned"? UI policy.
The rule must hold on imports, integrations and background scripts? Data policy with Apply to imports on.
You want both integrity and instant form feedback? One data policy with Use as UI policy on the client, don't maintain two records that can drift apart.
The logic is too complex for condition + actions (cross-field maths, async lookups)? Fall back to a client script or business rule, but only then.

Common mistakes

Relying on a UI policy for data integrity, an Import Set or REST insert sails straight past it because it never touched a form.
Creating a data policy but forgetting to tick Apply to imports, so the "mandatory" rule silently does nothing during loads.
Maintaining a separate UI policy and data policy for the same rule; they drift apart. Use one data policy with the client flag instead.
Setting actions to True/False when you meant Leave alone, causing two policies to fight over the same field.
Expecting a policy to override an ACL, it can't grant write access the user doesn't have.
Reaching for a business rule or client script where a no-code policy would have done the job in half the time.