3.2.1. UI Policies

💡 First Principle: Implementing dynamic, client-side logic on forms ensures that data is accurately collected and user experience is streamlined, directly supporting data quality for subsequent migrations and integrations.

🎯 Exam Tip: The three UI Policy field actions are mandatory, visible, and read-only — nothing else (a policy can also show or hide a whole related list through a UI Policy Related List Action, added once the policy is saved). Any question describing a UI Policy that 'queries a related table' or 'updates a field value' is describing a Client Script or Business Rule, not a UI Policy.

Scenario: A business user requests that the "Resolution Notes" field on the Incident form becomes mandatory only when the "State" changes to "Resolved." You need to implement this without writing code.

While previously discussed in the context of form configuration (2.3.3), UI Policies play a crucial role in the broader context of data migration and integration by ensuring the quality and consistency of data at the point of entry. The fundamental 'why' of UI Policies is to control how fields on a form behave dynamically based on user input or other conditions, guiding users towards correct data entry and preventing the submission of incomplete or inconsistent information. This front-end validation reduces the need for complex backend processing or cleaning data that has been incorrectly entered, which is vital when that data will be consumed by integrations or used for migrations.

Key aspects and their relevance to Data Migration/Integration:

• Dynamic Form Behavior: UI Policies can make fields mandatory, visible, or read-only based on conditions.
  • Relevance: Ensures critical data required for integrations (e.g., a unique identifier for an external system, a required status for a webhook trigger) is always collected and in the correct state. For example, if an incident category is "Integration Error," make a "System Affected" field mandatory.
• Preventing Invalid Data Entry: By setting fields as read-only or hiding irrelevant ones, UI Policies reduce the chance of users entering data that might conflict with integration requirements or be unnecessary for a specific data mapping.
  • Relevance: Supports the "Data Integrity" first principle by controlling data quality at source, making the data more reliable for migration tools like Import Sets (3.1.3) or direct integrations.
• Simplifying User Interface: Hiding irrelevant fields based on conditions streamlines the form, making it easier for users to complete.
  • Relevance: While not directly about data migration, a simplified, intuitive input process leads to higher quality, less ambiguous data that is easier to map and integrate programmatically.
• Order and Global Scope: UI Policies are processed in order, and can be applied globally across all views of a form or specifically for certain views. This ensures consistent data validation regardless of how the user accesses the form.
  • Relevance: Maintains a consistent data input standard, ensuring that all records, regardless of their source (manual entry or via a template), adhere to the same validation rules, which is critical for consistent integration behavior.
• Where scripts run, and what cannot be hidden: A UI Policy's Execute if true / Execute if false scripts run in the desktop UI by default; set Run scripts in UI type to include Mobile / Service Portal when they must also run in the portal. Separately, the platform will not hide a mandatory field that has no value, so a hide action waits until the field is filled in or stops being mandatory.
  • Relevance: A policy that behaves on the desktop form but not in the portal, or a field that refuses to hide, is usually one of these two rules rather than a broken condition.
• No-Code Configuration: UI Policies are configured declaratively, without scripting.
  • Relevance: Easy to implement and maintain, reducing technical debt that could complicate future integrations or upgrades.

By intelligently applying UI Policies, administrators contribute to a robust data input strategy that directly supports seamless data migration and reliable integration processes by ensuring the quality and structure of data at its origin.

The limit of a UI Policy — and where a Data Policy takes over: a UI Policy only acts on a form. Records created by an Import Set, a web service call or a script never load a form, so a UI Policy cannot stop them arriving with a required field empty. A Data Policy enforces the same kind of rule on the server, whenever a record is inserted or updated.

• Apply to import sets — the policy also checks records arriving through an Import Set.
• Use as UI Policy on client — the same rule is also shown on the form, so users see the field marked mandatory before they submit.
• An existing UI Policy can be converted to a Data Policy (the Convert this to Data Policy related link) when a rule must hold for every source of data — provided it is global, runs no scripts, and has no visibility actions.

🎯 Exam Tip: "Must always be populated, even for records created by an import or an API" means Data Policy. "Show, hide or require a field on the form" means UI Policy.

Catalog items use Catalog UI Policies. Catalog variables are not fields on a table, and the requester fills them in on the catalog item's order form before any Requested Item exists, so a standard UI Policy cannot act on them. A Catalog UI Policy applies to a specific catalog item (or to every item that uses a variable set) and makes its variables mandatory, visible or read-only based on other variable values, with no scripting. It can also be set to apply when those variables appear on the Requested Item or Catalog Task form (see 2.4.2).

💡 Tip: Always try to achieve form logic with a UI Policy before resorting to a Client Script (3.2.4). UI Policies are more performant, easier to maintain, and less likely to break during upgrades, which is crucial for the longevity and reliability of your data.

⚠️ Common Pitfall: Using Client Scripts for simple form logic that could be achieved with a UI Policy. This violates the "Configuration over Customization" principle and adds unnecessary complexity.

Key Trade-Offs:

• Simplicity (UI Policies) vs. Complexity (Client Scripts): UI Policies are simpler and preferred for basic dynamic form behavior. Client Scripts offer more power but introduce scripting complexity.

Reflection Question: How do UI Policies contribute to data quality and consistency, which are crucial for successful data migrations and integrations in ServiceNow?