ServiceNow UI Policy Explained

What UI Policy Is and How It Works

A UI Policy is a ServiceNow rule that controls form behaviour at runtime. When a user opens a form, UI Policies run in the background, reading the data on the form and applying changes: hiding or showing fields, making fields mandatory or read-only, changing labels or help text. UI Policies execute in the browser so changes happen instantly without server round-trips. For example, a UI Policy can hide a repair priority field unless the form type is set to warranty repair. If a user changes the form type, the field appears or disappears instantly.

UI Policies are separate from Access Control Lists (ACLs) which determine whether a role can edit a field. ACLs are role-based and permanent. UI Policies are data-based and dynamic, allowing the same form to show different fields to the same user depending on the data in the form.

Where UI Policy Lives in the Platform

UI Policies are configured in the System UI application, under UI Policies. Each policy targets a specific table: incident, request, change, or custom tables. A single table can have multiple UI Policies, each with different conditions. When a form loads, the system evaluates all policies that apply to that table and applies their actions. If two policies conflict (one hides a field, another makes it visible), the result depends on policy order; policies are evaluated top-to-bottom and can override each other.

UI Policies are managed under System UI in their own list, separate from UI Actions. You can view all policies for a table at a glance, or drill into one to edit its conditions and actions.

A Worked Example: Conditional Repair Information

Consider an asset management scenario where technicians report hardware problems. The form has a field for defect category: cosmetic, functional or critical. If the defect is cosmetic, the repair priority can be low and the estimated cost is usually low. If the defect is critical, repair priority must be assigned and estimated cost is usually high. A UI Policy can enforce this.

The policy condition reads: if defect category is cosmetic, hide the repair priority field and set repair cost to low. If defect category is functional, show repair priority and repair cost as editable. If defect category is critical, show both fields, make repair priority mandatory and show a warning message. When a technician opens the form and selects a defect, the form instantly shows or hides fields without requiring a page reload. This guides the technician to enter data consistently with the defect type.

Building Conditions and Actions

Conditions use field values from the current form to determine whether the policy applies. Common conditions include field equality (status equals closed), field contains (description contains urgent) or date comparisons (created date is older than 30 days). Conditions can be combined with AND or OR logic, allowing complex scenarios. For example: if assigned group equals Network Team AND priority equals high, apply this policy.

Actions specify what to do when conditions are met. Common actions include making a field visible, hiding a field, making a field mandatory, or setting a field read-only. You can also display a message, disable a button or trigger additional workflow. Design actions to guide users to correct entries without being heavy-handed. A hidden field is less jarring than a field that appears and disappears.

Common Patterns and Use Cases

One common pattern is dependent fields: show additional detail fields only when a parent category is selected. For example, if request type is hardware, show fields for hardware type, model and quantity. If request type is software, hide those fields and show software name and version instead. Another pattern is mandatory fields that depend on status: when status changes to closed, make resolution field mandatory. A third pattern is warnings: if a user tries to mark high-priority work low-priority, show a warning message asking for confirmation.

UI Policies can also enforce business rules. If a change is affecting production and impacts a large number of users, make the change category mandatory and require impact analysis. If incident severity is critical, make escalation group mandatory and set response time requirement fields as read-only with calculated values. These policies guide teams to follow governance without requiring approval workflows for every decision.

Performance and Complexity Considerations

UI Policies are evaluated on form load and whenever a watched field changes. Too many policies or complex conditions can slow form loading. Design policies efficiently: use simple conditions where possible. Avoid watching rarely-changed fields if you do not need to act when they change. Test policies on real forms to ensure they do not noticeably slow performance. If a form has many interdependent fields, consider whether a script or workflow would be more appropriate than UI Policies.

Where UI Policies stop and server-side rules must take over

A UI Policy changes the form in the reader’s browser. It hides, shows, locks and requires fields for the person typing into the form. It does not stop the same record from being saved without that field when the record arrives through an import, an integration or an API call. Any requirement that must hold on every write needs a data policy or a business rule as well. Deciding that split is the first design task, because a team that relies on UI Policies for a control has a control that works only for people who happen to use the form.

Requirement	UI Policy	Data policy or business rule
Hide an optional field until a category is chosen	Right tool, and cheap to change	Not needed
Make a field required when a record closes	Shows the requirement to the person closing it early	Needed so imported or API-closed records cannot skip it
Lock a field after approval	Good for the form experience	Needed if the field must stay locked on every write path
Calculate a value shown to the user	Usually a client script or a UI action, not a policy	A business rule if the value must be stored

The table is about enforcement, not appearance. The user benefits from the UI Policy in every row, but only the server-side rule protects the data.

Finding and resolving conflicting policies on one table

Policy sprawl is a common failure. Over a long period a table collects policies written by different people for different projects, and two of them quietly disagree about the same field. The symptom is a field that flickers, or one that is mandatory on one tab and not on another. Diagnosis is mechanical, so work through it in a fixed order rather than editing the policy you suspect:

1. List every policy against the table, including inactive ones, and record the conditions and the fields each one acts on.
2. Group the policies by field. Any field acted on by more than one policy is a candidate for conflict.
3. For each candidate, write the combined behavior you want in one sentence, and check whether a single policy can deliver it alone.
4. Merge or retire the redundant policies in a test copy first, then test the form as each persona that uses it.
5. Record the decision in the table’s change notes so the next person does not reintroduce the overlap.

Keeping conditions cheap and testable

Conditions that compare simple values are easy to reason about. Conditions that depend on a chain of reference fields, or on dates computed from the current time, are where surprises often come from, because the form can look right when opened and wrong a few minutes later. Prefer a condition on a field the user can see. When a condition depends on something the user cannot see, say so in the policy’s description, and check the form immediately after the record changes state.

Policies also run in a fixed sequence, so a policy that sets a value and another that depends on it can behave differently depending on which fires first. If two policies must cooperate, give them a documented order or merge them. An order nobody wrote down is how a small edit breaks a form a long time later. Client-side behavior of this kind is discussed further in the client scripts and UI policies article.

A layout for a form with many dependent fields

Consider a request form where the category decides which of several detail fields appear, and each category carries its own mandatory rules. Writing one policy per category is tidy, but it produces a batch of policies that all touch the same fields. A single policy keyed on the category, with a short documented table showing which fields each value reveals, is easier to audit. Once the number of dependent values grows past what one reader can hold in their head, the form is usually better served by a catalog item with separate variable sets, which keeps each path’s fields where they belong.

Performance and the cost of watching too many fields

A policy re-evaluates when a field it depends on changes, so a long list of watched fields on a busy form adds work every time someone types. The effect is small for one policy and noticeable for many. Review the watched fields for each policy and remove any that do not change what the policy does. If a form is slow to load, check the policies on that table before blaming the browser or the network. The platform performance guide covers how to diagnose slow loads.

Questions administrators ask about UI Policies

Why does a field change when I open the form but not when I save it?

The policy may run only when a watched field changes, and the saved record may already hold the value that makes the policy stop applying. Check the conditions against the saved record, not the value you see after the page loads.

Can a UI Policy run on a list view?

UI Policies act on forms. Behavior on lists needs a different mechanism, and that choice should be made with the same enforcement question in mind.

Should every field that must be mandatory have a UI Policy?

No. A field that is always required can be set on the dictionary or the form layout. Use a policy only when the requirement depends on other values.

How do I tell whether a policy or a client script is causing a problem?

Turn off the suspect in a test copy and reproduce the behavior. If the behavior stops, that item was involved. Run the same test for the other, because both can produce the same symptom.

Next step

An audit of the policies on your busiest table often finds at least one enforcement gap and one conflict.