Mastering UI Policy Actions in ServiceNow: Beyond Simple Field Settings

In the world of ServiceNow development, creating intuitive and user-friendly interfaces is paramount. We want forms to guide users, highlight critical information, and prevent errors before they happen. While scripting can achieve almost anything, there’s a powerful, often underutilized, mechanism that handles a vast majority of these common form manipulations without a single line of code: UI Policy Actions.

Think of UI Policies as the brains behind dynamic form behavior. They listen for specific conditions to be met and then trigger actions. UI Policy Actions are the workhorses within this framework, directly influencing how users interact with fields on a form. This article dives deep into UI Policy Actions, exploring how to create them, their various configurations, and how they work in tandem with UI Policy conditions and the crucial ‘Reverse if false’ setting. We’ll also venture into related list actions and touch upon when and why you might need to leverage UI Policy Scripts for more complex scenarios. Let’s get started!

Understanding UI Policy Actions: The Core of Dynamic Forms

At their heart, UI Policy Actions are the specific instructions that a UI Policy executes when its defined conditions evaluate to true. Their primary purpose is to modify the attributes of form fields. Unlike scripting, which offers immense flexibility but can also introduce complexity and potential for errors if not managed carefully, UI Policy Actions provide a declarative, no-code approach to common UI manipulations. This makes them faster to implement, easier to maintain, and more accessible to administrators and junior developers.

UI Policy Actions focus on three key field attributes:

• Mandatory: This determines whether a user must provide a value for a field before submitting the record.
• Visible: This controls whether a field is displayed on the form.
• Read-only: This dictates whether a user can edit the value of a field.

The beauty of UI Policy Actions lies in their simplicity. You don’t need to be a scripting guru to make a field mandatory or hide it under certain circumstances. ServiceNow handles the underlying GlideForm (g_form) API calls for you. This abstraction layer is a significant benefit, reducing the learning curve and the potential for syntax errors.

When to Use UI Policy Actions vs. Client Scripts

This is a question that often comes up. While both can alter field attributes, the rule of thumb is to prefer UI Policy Actions whenever possible for the three core attributes (mandatory, visible, read-only). Why?

• Simplicity & Maintainability: No-code is inherently easier to understand and maintain than script.
• Performance: UI Policies generally have a lower performance overhead as they are pre-compiled and optimized by the platform.
• Order of Execution: UI Policies run before Client Scripts by default, which can be important for predictable behavior.

You’d typically turn to UI Policy Scripts (or standalone Client Scripts) when:

• You need to perform actions beyond setting mandatory, visible, or read-only states (e.g., setting field values based on complex logic, clearing fields, performing calculations).
• You need to interact with related lists dynamically (though UI Policy Related List Actions handle visibility).
• You need more granular control over when the logic runs, or need it to run in response to specific events beyond simple form load or field changes.
• You’re dealing with platform-specific behaviors or advanced DOM manipulation (though this is rare and generally discouraged).

1.6.1 Creating UI Policy Actions: Step-by-Step

Let’s walk through the process of creating a UI Policy Action. This is where you define what happens when your UI Policy’s conditions are met.

1. Navigate to Studio: Open your application in ServiceNow Studio.
2. Create or Open a UI Policy: You can either create a new UI Policy or open an existing one for editing. If you’re creating a new UI Policy, remember to save it first; the related lists will only appear after the initial save.
3. Locate the UI Policy Actions Related List: Scroll down the UI Policy form until you find the “UI Policy Actions” related list.
4. Click “New”: This will open a form to create a new UI Policy Action.
5. Configure the UI Policy Action: This is the core of the process. You’ll see a few key fields:
   • Field name: This is a crucial dropdown. Select the specific field on the form that you want this action to affect. For example, if you want to make the “Assignment group” field mandatory when a “State” is “In Progress,” you would select “Assignment group” here.
   • Mandatory: This field controls the “mandatory” attribute. You have three options:
     • True: Makes the selected field mandatory.
     • False: Makes the selected field not mandatory.
     • Leave alone: This is a very important option. It means this specific UI Policy Action will *not* change the mandatory state of the field. The field will retain whatever its mandatory state was before this UI Policy was evaluated (or as determined by other UI Policies or business rules).
   • Visible: Similar to Mandatory, this controls the visibility of the field.
     • True: Makes the field visible.
     • False: Hides the field.
     • Leave alone: The field’s visibility is not affected by this action.
   • Read-only: This controls whether the field can be edited.
     • True: Makes the field read-only.
     • False: Makes the field editable.
     • Leave alone: The field’s read-only status is not affected by this action.
6. Clear the field value (Optional): If you want to ensure that any existing data in the field is removed when this action is applied, check the “Clear the field value” checkbox. This is particularly useful when hiding a field or making it read-only – you might not want outdated information to persist.
7. Click “Submit”: Once you’ve configured your action, save it.

Real-World Example:
Imagine a “Problem” form. When the “State” is set to “Resolved,” we want the “Resolution Notes” field to become mandatory, visible, and editable, allowing the user to enter details about how the problem was resolved.

UI Policy: “Make Resolution Notes Mandatory when Resolved”

Condition: State is Resolved

UI Policy Action:

• Field name: Resolution Notes
• Mandatory: True
• Visible: True
• Read-only: False

When the “State” is “Resolved,” the “Resolution Notes” field will be immediately visible, required, and editable.

The “Reverse if False” Option: Controlling Behavior When Conditions Fail

This is where UI Policies truly shine and differentiate themselves from simple one-off script executions. What happens to your field attributes when the UI Policy’s conditions are no longer met (i.e., the condition tests false)? ServiceNow gives you two distinct options, controlled by the “Reverse if false” checkbox on the UI Policy record itself.

1.6.2 How ServiceNow Knows Which to Do: The Power of “Reverse if False”

When you create a UI Policy, you’ll find a checkbox labeled “Reverse if false.” Its behavior significantly impacts how your UI Policy Actions are applied.

A. “Reverse if False” is Selected (Default Behavior)

This is the default and most common setting. When “Reverse if false” is checked, ServiceNow intelligently reverts the actions taken by the UI Policy’s Actions when the conditions are no longer true.

• If an action set a field to Mandatory: True, and the condition later becomes false, this action will be reversed, making the field Mandatory: False.
• If an action set a field to Visible: False, and the condition later becomes false, this action will be reversed, making the field Visible: True.
• If an action set a field to Read-only: True, and the condition later becomes false, this action will be reversed, making the field Read-only: False.

Crucially, any attribute set to “Leave alone” in the UI Policy Action remains unaffected, both when the condition is true and when it becomes false.

Continuing the “Problem” Example:
Let’s assume our UI Policy “Make Resolution Notes Mandatory when Resolved” has “Reverse if false” checked.

Scenario:
1. A Problem record is created, “State” is “New.” “Resolution Notes” are not mandatory, not visible, and editable.
2. The user changes “State” to “Resolved.” The UI Policy condition is met.
3. The UI Policy Action makes “Resolution Notes” Mandatory: True, Visible: True, Read-only: False. The user can now see and must fill out “Resolution Notes.”
4. Later, the user realizes the state should be “Closed.” They change “State” to “Closed.”
5. Now, the UI Policy condition “State is Resolved” is FALSE. Because “Reverse if false” is checked, ServiceNow automatically reverts the actions. “Resolution Notes” will become Mandatory: False, Visible: False, Read-only: True (or whatever their default state was before the UI Policy). This ensures cleanup and prevents the user from being forced to fill out notes if the problem isn’t resolved.

B. “Reverse if False” is NOT Selected

If you uncheck “Reverse if false,” the behavior changes dramatically. In this case, when the UI Policy’s conditions evaluate to false, no UI Policy Action logic is applied for that specific UI Policy. The fields will simply retain whatever state they were in before the UI Policy’s conditions became false.

• The attributes set by the UI Policy Actions when the condition was true will persist, even if the condition is no longer met.

Scenario:
Let’s use the same “Problem” example, but this time, we uncheck “Reverse if false” on the UI Policy.

1. User changes “State” to “Resolved.” “Resolution Notes” become Mandatory: True, Visible: True, Read-only: False.
2. The user then changes “State” to “Closed.” The condition “State is Resolved” is now FALSE.
3. Because “Reverse if false” is unchecked, the actions that were applied when the state was Resolved (Mandatory: True, Visible: True, Read-only: False) remain in effect. The “Resolution Notes” field will still be mandatory, visible, and editable, even though the problem is no longer in a “Resolved” state. This is usually NOT the desired behavior and can lead to confusing forms.

1.6.3 Creating UI Policy Related List Actions: Controlling List Visibility

Beyond individual fields, you often need to control the visibility of entire related lists on a form. ServiceNow provides a specific type of action within UI Policies for this purpose: UI Policy Related List Actions.

Consider a “Problem” form. It typically has numerous related lists, such as “Incidents,” “Affected CIs,” “Problem Tasks,” “Change Requests,” etc. You might want to show or hide these lists based on the problem’s state or type.

Here’s how to create them:

1. Navigate to Studio: Open your application in Studio.
2. Create or Open a UI Policy: As before, ensure your UI Policy is saved.
3. Locate the UI Policy Related List Actions Related List: Scroll down the UI Policy form to find this specific related list.
4. Click “New”: This opens the form for a new Related List Action.
5. Configure the UI Policy Related List Action:
   • List name: From the dropdown, select the specific related list you want to control. These are the names that appear as tabs or headers on your form.
   • Visible: This field determines the visibility of the selected related list.
     • True: Makes the related list visible.
     • False: Hides the related list.
     • Leave alone: The visibility of the related list is not affected by this action.
6. Click “Submit”: Save your related list action.

Real-World Example:
On a “Change Request” form, you want to show the “Emergency Change Tasks” related list only when the “Type” of change is “Emergency.”

UI Policy: “Show Emergency Tasks for Emergency Changes”

Condition: Type is Emergency

UI Policy Related List Action:

• List name: Emergency Change Tasks
• Visible: True

When the “Type” is set to “Emergency,” the “Emergency Change Tasks” related list will appear. If the “Type” is changed to anything else, and assuming “Reverse if false” is checked on the UI Policy, the “Emergency Change Tasks” list would then be hidden again.

1.6.4 UI Policy Scripts: When No-Code Isn’t Enough

While UI Policy Actions are powerful for the three core attributes, there are times when you need to perform more complex logic or actions that go beyond simply toggling mandatory, visible, or read-only states. This is where UI Policy Scripts come into play.

UI Policy Scripts allow you to execute custom JavaScript code on the client-side, triggered by the UI Policy’s conditions. They are invaluable for:

• Setting field values: Populate fields based on calculations or lookups.
• Clearing fields: Programmatically clear values.
• Performing validations: More complex validation logic than what UI Policies alone can handle.
• Interacting with UI elements: Though this should be used sparingly.
• Executing sequences of actions: For example, hiding a field, clearing its value, and then making another field mandatory.

Accessing UI Policy Scripts

Scripting fields are not visible by default. To enable them:

1. Open your UI Policy record.
2. In the header, click the “Advanced” view toggle or look for a related link that says “Show scripting fields.” You might also need to enable “Run scripts” on the UI Policy itself.

Once enabled, you’ll see two primary scripting fields:

• Execute if true script: This script runs when the UI Policy’s conditions are met (tests true).
• Execute if false script: This script runs when the UI Policy’s conditions are not met (tests false).

Writing Your Scripts

Both scripting fields will have an `onCondition()` function automatically inserted. This is the function that the UI Policy framework calls at runtime. Your custom script logic should reside within this function.

Example Structure:

function onCondition() {
    // Your custom script logic goes here
    // Use g_form API to interact with fields
    g_form.setValue('field_name', 'some_value');
    g_form.setMandatory('another_field', true);
}

Platform Specificity and UI Types

A critical consideration for UI Policy Scripts is their execution platform. By default, UI Policy Scripts only execute on Desktop/tablet interfaces. If you need your scripts to run on mobile devices or other platforms, you need to configure the “Run scripts in UI type” field on the UI Policy.

• Desktop: Scripts run on desktop web interfaces.
• Mobile: Scripts run on mobile web interfaces (e.g., ServiceNow Agent mobile app).
• All: Scripts run on both desktop and mobile.

Real-World Example:
On an “Incident” form, when the “Category” is “Software” and the “Subcategory” is “Login Issue,” you want to automatically set the “Impact” to “2 – Medium” and the “Urgency” to “2 – High.” You also want to make a custom field “Trouble Ticket ID” visible and mandatory.

UI Policy: “Set Impact/Urgency for Login Issues”

Conditions: Category is Software AND Subcategory is Login Issue

Reverse if false: Checked

UI Policy Actions (for fields not handled by script):

• Field name: Trouble Ticket ID
• Visible: True
• Mandatory: True

UI Policy Script (Execute if true):

function onCondition() {
    g_form.setValue('impact', '2'); // Assuming '2' is the backend value for Medium
    g_form.setValue('urgency', '2'); // Assuming '2' is the backend value for High
}

When the conditions are met, the script sets the impact and urgency, and the UI Policy Action makes “Trouble Ticket ID” visible and mandatory. If the conditions are no longer met, “Reverse if false” will revert the “Trouble Ticket ID” visibility and mandatory state, and the “Execute if false” script (if present) would run to potentially clear values or reset other fields.

Troubleshooting Common UI Policy Action Issues

While UI Policies are generally robust, you might encounter situations where they don’t behave as expected. Here are some common pitfalls and how to address them:

Interview Relevance: UI Policy Actions

Understanding UI Policies and their actions is fundamental for any ServiceNow role involving form customization, administration, or development. You’re almost guaranteed to encounter questions about this topic in interviews.

Sample Interview Question: “Describe a scenario where you would use a UI Policy Action, and explain the importance of the ‘Reverse if false’ option in that scenario.”

Your Answer Should Cover: A practical example (like making a field mandatory or visible), the specific attributes you’d set, and then a clear explanation of how ‘Reverse if false’ ensures the field returns to its normal state when the condition is no longer met, preventing unintended side effects.

Conclusion

UI Policy Actions are a cornerstone of dynamic and user-friendly forms in ServiceNow. By mastering their creation, configuration, and the subtle but crucial “Reverse if false” option, you can significantly enhance the user experience, reduce data entry errors, and streamline workflows without resorting to complex scripting. Remember to leverage them for mandatory, visible, and read-only attributes first, and then turn to UI Policy Scripts for more advanced logic when necessary. As you continue your ServiceNow journey, a solid understanding of UI Policies and their actions will prove invaluable.