UI Policies

UI Policies in ServiceNow – A Comprehensive Guide for CAD Exam Preparation

Introduction

UI Policies are one of the most important and frequently tested topics on the ServiceNow Certified Application Developer (CAD) exam. Understanding how they work, when to use them, and how they differ from other mechanisms like Client Scripts and Data Policies is essential for both real-world development and exam success.

Why Are UI Policies Important?

UI Policies are important because they provide a no-code / low-code way to dynamically control the behavior of form fields on the client side. They allow developers and administrators to:

• Make fields mandatory, read-only, or visible/hidden based on conditions — without writing a single line of code in many cases.
• Improve user experience by showing only relevant fields and enforcing data quality at the point of entry.
• Reduce the reliance on complex Client Scripts, making the platform easier to maintain and upgrade.
• Enforce consistent business rules on the form, ensuring users provide the correct information based on the current state of a record.

ServiceNow recommends using UI Policies over Client Scripts whenever possible for setting field attributes (mandatory, read-only, visible), because they are easier to configure, easier to debug, and follow best practices.

What Is a UI Policy?

A UI Policy is a client-side mechanism in ServiceNow that dynamically changes the behavior and appearance of fields on a form. It consists of two main parts:

1. Conditions – A set of criteria (defined using a condition builder) that determine when the policy should be applied.
2. UI Policy Actions – A set of actions that define what happens to specific fields when the conditions are met (e.g., make a field mandatory, read-only, or hidden).

UI Policies are defined per table and can be configured to apply globally or to specific views.

Key Properties of a UI Policy:

• Table – The table the UI Policy applies to.
• Short Description – A brief description of the policy's purpose.
• Conditions – When the policy should activate (e.g., State is Resolved).
• On Load – A boolean (true/false) field that determines whether the UI Policy runs when the form first loads. If set to true, the policy evaluates its conditions when the form loads. If false, it only evaluates when a field in the condition changes.
• Reverse if False – When set to true, the field attributes revert to their previous state if the conditions are no longer met. This is a critical concept for the exam.
• Inherit – Determines whether the policy applies to extended (child) tables.
• Global – If true, the policy applies to all views of the form; otherwise, it applies only to the specified view.
• Order – Determines the sequence in which UI Policies are executed. Lower numbers execute first. This matters when multiple UI Policies apply to the same form.
• Active – Enables or disables the UI Policy.

UI Policy Actions:

Each UI Policy can have one or more UI Policy Actions, which define what happens to fields when the conditions are met. Each action specifies:

• Field Name – The field to act upon.
• Mandatory – Set to true (make mandatory), false (make not mandatory), or Leave alone (do not change).
• Visible – Set to true (show), false (hide), or Leave alone.
• Read Only – Set to true (make read-only), false (make editable), or Leave alone.

How Do UI Policies Work?

Here is the step-by-step process of how UI Policies function:

1. Form Load:
When a user opens a form, ServiceNow loads all active UI Policies that apply to the table and view. If the On Load field is set to true, the conditions are evaluated immediately. If conditions are met, the UI Policy Actions are applied to the form fields.

2. Field Change:
When a user changes a value on the form, ServiceNow re-evaluates the conditions of all active UI Policies. If the conditions are now met, the corresponding UI Policy Actions are applied.

3. Reverse if False:
If Reverse if False is set to true and the conditions are no longer met (e.g., the user changes the field back), the field attributes revert to their default state. If set to false, the changes made by the UI Policy persist even after the conditions are no longer true.

4. Order of Execution:
UI Policies execute in order based on the Order field. If two UI Policies conflict (e.g., one sets a field to mandatory and another sets it to not mandatory), the one with the higher order number (which runs last) wins.

5. Script Support:
UI Policies also have an optional Script section that allows developers to write custom JavaScript. This is used for scenarios where the condition builder and standard actions are not sufficient. The script section has two parts:
• Execute if true – Runs when the conditions are met.
• Execute if false – Runs when the conditions are not met (this replaces the need for Reverse if False when scripting is involved).

UI Policies vs. Other Mechanisms

UI Policies vs. Client Scripts:
• UI Policies are the preferred method for setting mandatory, read-only, and visible field attributes.
• Client Scripts (particularly onChange scripts) can do the same thing but require JavaScript and are harder to maintain.
• ServiceNow best practice: Use UI Policies for field attribute changes; use Client Scripts for more complex logic like GlideAjax calls or field value manipulation.

UI Policies vs. Data Policies:
• UI Policies are client-side only — they enforce rules on the form but do NOT enforce rules when records are updated via server-side processes (like web services, import sets, or Business Rules).
• Data Policies can enforce mandatory and read-only attributes on both the client side and server side. They are useful when you need enforcement regardless of how the data enters the system.
• If you need a field to be mandatory both on the form AND via integrations/APIs, use a Data Policy.

UI Policies vs. ACLs (Access Control Lists):
• UI Policies control the visual behavior of fields on the form (read-only, visible, mandatory).
• ACLs control security access to fields, rows, and tables. Even if a UI Policy makes a field read-only, a knowledgeable user could bypass it (since it's client-side). ACLs provide server-side enforcement.
• For true security, always use ACLs in addition to (or instead of) UI Policies.

Important Concepts for the Exam

1. Reverse if False – Understand exactly what this does. When true, the field reverts to its previous state when conditions are no longer met. When false, changes persist.

2. On Load – If On Load is false, the UI Policy will NOT evaluate when the form first loads. It will only evaluate when a field referenced in the condition changes. If you need the policy to apply when the form opens, set On Load to true.

3. Order of Execution – Higher order number = runs later = wins in case of conflicts. This is the opposite of how some people intuitively think about priority.

4. UI Policy Actions – Remember the three options: Mandatory, Visible, Read Only. Each can be set to true, false, or Leave alone.

5. Client-Side Only – UI Policies are enforced on the client side only. They do NOT protect data from server-side changes. This is a common exam question.

6. Scripting in UI Policies – You can add scripts to UI Policies for advanced logic. The scripts run on the client side and have access to the g_form API (GlideForm) to manipulate the form.

7. Inheritance – A UI Policy on a parent table (like Task) can apply to child tables (like Incident, Change Request) if the Inherit checkbox is selected.

8. Best Practice Hierarchy – ServiceNow recommends: Use UI Policies first for simple field attribute changes. Use Client Scripts when more complex logic is needed. Use Data Policies when server-side enforcement is required.

Exam Tips: Answering Questions on UI Policies

Here are targeted strategies for handling UI Policy questions on the CAD exam:

Tip 1: Read the Scenario Carefully
Many exam questions describe a scenario and ask you to choose the best approach. If the requirement is simply to make a field mandatory, read-only, or hidden based on a condition, the answer is almost always UI Policy — not a Client Script.

Tip 2: Watch for the "Server-Side" Trap
If a question asks about enforcing field requirements when data comes from an import, web service, or API, UI Policies will NOT work. The correct answer in those cases is typically a Data Policy or a Business Rule.

Tip 3: Understand Reverse if False Thoroughly
Expect at least one question that tests your understanding of Reverse if False. Remember: if it's true, the UI Policy's actions are undone when conditions are no longer met. If false, the changes stick. Think of it like an undo button.

Tip 4: Know the Order of Execution
If two UI Policies conflict, the one with the higher order value takes precedence (because it runs last and overwrites the earlier one). This is a common trick question.

Tip 5: Remember On Load Behavior
If the question says the UI Policy should apply when the form first opens (e.g., on an existing record), make sure On Load is set to true. If On Load is false, the policy only triggers when the user changes a field that is part of the condition.

Tip 6: Differentiate Between UI Policy, Client Script, and Data Policy
A common question format is: "Which of the following is the BEST approach to...?" If the scenario involves form field attributes, choose UI Policy. If it involves complex client-side logic, choose Client Script. If it involves server-side enforcement of field rules, choose Data Policy.

Tip 7: Know That UI Policies Can Contain Scripts
Some questions may reference the scripting capability of UI Policies. Remember that UI Policy scripts have access to g_form and run on the client side. The two script sections are Execute if true and Execute if false.

Tip 8: Remember the "Leave Alone" Option
When setting UI Policy Actions, Leave alone means the UI Policy does not change that particular attribute. This is important when you only want to affect one attribute (e.g., make mandatory) without affecting others (e.g., visibility).

Tip 9: Consider Table Inheritance
If a question mentions applying a policy to multiple related tables (like all Task-based tables), look for answers that reference the Inherit option on the parent table's UI Policy rather than creating duplicate UI Policies on each child table.

Tip 10: Eliminate Wrong Answers Systematically
On the exam, you can often eliminate answers by asking: Does this require server-side enforcement? (If yes, UI Policy is wrong.) Does this require complex scripting? (If yes, a Client Script may be better.) Is this just about making a field mandatory/hidden/read-only? (If yes, UI Policy is the best answer.)

Summary

UI Policies are a powerful, declarative tool in ServiceNow for dynamically controlling form field behavior. They are client-side only, easy to configure, and are the recommended best practice for setting mandatory, visible, and read-only attributes on forms. For the CAD exam, focus on understanding Reverse if False, On Load, order of execution, and the differences between UI Policies, Client Scripts, and Data Policies. Mastering these concepts will help you confidently answer UI Policy questions on your certification exam.