Mastering UI Policies in ServiceNow: A Developer’s Guide

In the dynamic world of ServiceNow development, creating intuitive and user-friendly forms is paramount. Users expect their applications to behave intelligently, adapting to their inputs and guiding them through processes seamlessly. This is where UI Policies step into the spotlight. While Client Scripts have long been the go-to for client-side logic, UI Policies offer a powerful, and often simpler, way to control form and field behavior without necessarily diving deep into scripting.

This article will demystify UI Policies, breaking down their core concepts, how to create and configure them, and how they stack up against their scripting counterpart, Client Scripts. Whether you’re a seasoned developer looking to refine your toolkit or a newcomer eager to understand ServiceNow’s client-side capabilities, this guide will equip you with the knowledge to leverage UI Policies effectively.

Understanding the Power of UI Policies

At their heart, UI Policies are about making your forms smarter. They allow you to dynamically alter the behavior of fields and even entire forms based on specific conditions. Think about common scenarios:

• Making a “Resolution Code” field mandatory only when the “State” is set to “Resolved”.
• Hiding a “Reassignment Comments” field until the “State” changes to “Work in Progress”.
• Making a field read-only to prevent accidental edits after a certain stage.

These are precisely the types of interactions that UI Policies are designed to handle. The beauty of UI Policies lies in their ability to achieve these dynamic changes with minimal or no scripting, making them an accessible and efficient tool for developers of all levels.

Creating and Configuring UI Policies

The process of adding any new file to your application in ServiceNow Studio is standardized, ensuring consistency across different file types. For UI Policies, it’s a straightforward three-step process:

1. Initiating the Creation Process

Within your ServiceNow Studio application, locate and click on the “Create Application File” link. This action opens a modal or panel where you’ll select the type of file you wish to create.

2. Selecting the File Type

From the list of available file types, choose “UI Policy”. This tells ServiceNow you’re about to define a new set of client-side behaviors.

3. Configuring the New UI Policy

Once selected, you’ll be presented with the UI Policy configuration form. This is where you define the “what” and “when” of your policy.

UI Policy Configuration Views: Default vs. Advanced

UI Policies offer two distinct views for configuration: Default and Advanced. The Default view presents a streamlined set of commonly used fields, making it quick to set up basic policies. For more granular control and advanced functionality, you’ll want to switch to the Advanced view, which exposes all available configuration fields.

Key Configuration Fields Explained

• Table: This is a fundamental field. You must specify the table (and therefore, the form) to which this UI Policy will apply. For example, if you want to control fields on the Incident form, you’d select the “Incident” table.
• Application: This field dictates the scope of your UI Policy, linking it to the specific application it belongs to. This helps with organization and management within your ServiceNow instance.
• Active: A simple toggle. When checked, the UI Policy is enabled and will execute its logic. Unchecking it effectively disables the policy without deleting it, a handy feature for testing or temporarily suspending behavior.
• Short description: This is your primary identifier for a UI Policy, especially during debugging. Since UI Policies don’t have a dedicated “Name” field, a clear, concise, and descriptive short description is crucial. It should tell you at a glance what the policy does. Think of it as a descriptive label.
• Order: When multiple UI Policies are defined for the same table, the “Order” field determines the sequence in which they are evaluated. UI Policies are processed in ascending order of their “Order” value (lowest to highest).
DEVELOPER TIP: To facilitate future additions and modifications without extensive reordering, it’s a best practice to leave gaps between your “Order” field values. Instead of using consecutive numbers like 1, 2, 3, use increments of 100 (e.g., 100, 200, 300). This provides ample room to insert new UI Policies between existing ones.
• Condition: This is the trigger for your UI Policy. It’s a logical expression that, when evaluated as true, causes the UI Policy’s actions to execute. You can define conditions based on field values, using operators like “is,” “is not,” “starts with,” “contains,” etc.
IMPORTANT: If you leave the “Condition” field blank, the condition is considered to be always true. This means the UI Policy logic will execute every time there’s a change to any field value on the form, or on load if “On load” is selected. Use this with caution!
• Global: When this checkbox is selected, the UI Policy will apply to all views of the specified table. This means the logic will execute regardless of which form view the user is currently using.
• View: This field is only visible and relevant when the “Global” checkbox is NOT selected. Here, you can specify a particular view to which the UI Policy should apply. A UI Policy can only interact with fields that are present in the selected form view. If this field is left blank (and “Global” is not selected), the UI Policy will apply to the “Default” view.
• On load: If checked, the UI Policy’s conditions are evaluated not only when field values change but also when the form initially loads. This is essential for setting initial field states based on pre-existing data.
• Reverse if false: This is a critical setting that dictates the behavior when the UI Policy’s condition evaluates to false.
• If checked (and it’s the default), when the condition is false, the UI Policy will perform the opposite of the actions defined for when the condition is true. For example, if an action makes a field mandatory (true), and the condition becomes false, this option will make the field not mandatory (false).
• If unchecked, when the condition is false, no UI Policy Action logic is applied, and the form elements retain their current state.
• Inherit: When selected, this option ensures that the UI Policy’s logic is also executed for forms whose tables extend from the table specified in the UI Policy. This is incredibly useful for hierarchical table structures, allowing a policy on a parent table to influence child tables.

UI Policy Actions: Defining What Happens

UI Policies aren’t just about deciding *when* something happens; they’re also about defining *what* happens. This is handled by UI Policy Actions. These actions allow you to dynamically control three key attributes of form fields:

• Mandatory: Makes a field a required field.
• Visible: Shows or hides a field.
• Read only: Makes a field non-editable.

The significant advantage here is that you can set these attributes without writing any JavaScript. ServiceNow provides a user-friendly interface to configure these actions directly.

Creating UI Policy Actions

The process is integrated within the UI Policy creation or editing workflow:

1. Access the UI Policy: Either create a new UI Policy or open an existing one for editing in Studio.
2. Navigate to the Related List: Scroll down to the “UI Policy Actions” related list. If you’re creating a new UI Policy, you’ll need to save it first for this related list to appear.
3. Add a New Action: Click the “New” button within the UI Policy Actions related list.
4. Configure the Action:
   • Field name: Select the specific field on your form that you want to control.
   • Set Attributes: For Mandatory, Visible, and Read-only, you have three options:
     • True: Apply the attribute (e.g., make the field mandatory).
     • False: Remove the attribute (e.g., make the field optional).
     • Leave alone: This is crucial. It means this specific UI Policy Action will not change the current state of this attribute. The field’s existing attribute value will remain unaffected by this particular action.
   • Clear the field value: If you want to ensure that any existing data in the field is wiped clean when the UI Policy Action is triggered, check this option. This is particularly useful for fields that should only be populated under specific circumstances.
5. Save the Action: Click the “Submit” button to save your UI Policy Action.

When the UI Policy’s condition evaluates to true, all configured UI Policy Actions will be applied. For example, if the condition is met, a specific field might be set to ‘Read only’ while its ‘Mandatory’ and ‘Visible’ attributes remain unchanged (if set to ‘Leave alone’).

What Happens When the Condition is False?

As discussed with the “Reverse if false” option, there are two paths:

• No action is taken: If “Reverse if false” is unchecked, and the condition becomes false, the form fields simply revert to their state before the condition was met, or remain as they were if no prior condition had been met. The specific UI Policy Action settings for the “false” state are ignored.
• The opposite action is taken: If “Reverse if false” is checked (the default), the UI Policy will undo the actions it performed when the condition was true. If a field was made mandatory, it becomes optional. If it was hidden, it becomes visible. Attributes set to “Leave alone” in the action are unaffected by this reversal.

UI Policy Related List Actions

Beyond form fields, UI Policies can also control the visibility of Related Lists. This is incredibly useful for tailoring the user experience based on context. For instance, on a Problem form, you might only want to display the “Incidents” related list if the problem is in a specific state.

Creating Related List Actions

1. Access the UI Policy: Navigate to or create your UI Policy.
2. Navigate to the Related List: Scroll to the “UI Policy Related List Actions” related list. Again, save the UI Policy first if it’s new.
3. Add a New Action: Click the “New” button.
4. Configure the Action:
   • List name: Select the specific related list you want to control (e.g., “Incidents,” “Affected CIs”).
   • Visible:
     • True: Make the related list visible.
     • False: Hide the related list.
     • Leave alone: Do not change the visibility of the related list.
5. Save the Action: Click “Submit”.

When the UI Policy condition is true, the specified related list actions will take effect. For example, an “Incidents” related list could be hidden.

UI Policy Scripts: For More Complex Logic

While UI Policy Actions excel at managing visibility, mandatory, and read-only states without scripting, sometimes you need more sophisticated logic. This is where UI Policy Scripts come in. They allow you to execute custom JavaScript code based on your UI Policy conditions.

Enabling and Using UI Policy Scripts

The scripting fields are only visible in the Advanced view of the UI Policy. To make them appear, you must check the “Run scripts” option within the UI Policy configuration.

• Execute if true: This script will run when the UI Policy’s condition evaluates to true.
• Execute if false: This script will run when the UI Policy’s condition evaluates to false.

You write your script logic inside the onCondition() function, which is automatically populated when you enable scripting. This function is invoked by the UI Policy at runtime.

Real-world example: Imagine a scenario where you need to populate a “Description” field based on a “Category” and “Subcategory” selection. You could use an “Execute if true” script to build a descriptive string and set it on the Description field using the GlideForm API (e.g., g_form.setValue('description', 'Details for ' + categoryValue + ' - ' + subcategoryValue);).

Platform Specificity of UI Policy Scripts

It’s vital to understand that UI Policy scripts, by default, execute only on Desktop/tablet interfaces. If you need your scripts to run on mobile devices as well, you must explicitly configure this using the “Run scripts in UI type” field within the UI Policy. You can select “All,” “Desktop,” or “Mobile” to dictate where the scripts will execute.

Client Scripts vs. UI Policies: Choosing the Right Tool

Both Client Scripts and UI Policies operate on the client-side and share access to the same powerful GlideForm API. So, when do you choose one over the other? This is a common point of confusion for developers, but a clear understanding can significantly streamline your development process.

Here’s a comparative look:

Key Differentiators:

• Execution Order: UI Policies always execute *after* Client Scripts. This means if there’s conflicting logic, the UI Policy’s behavior will take precedence. This is a crucial aspect to remember during debugging.
• No Scripting for Attributes: The most significant advantage of UI Policies for many tasks is their ability to set field attributes (Mandatory, Visible, Read-only) without writing any code. This makes simple form validations and dynamic field behaviors much faster to implement and maintain.
• Form Save/Update Logic: Client Scripts are the only option when you need to execute logic during form submission or updates. UI Policies are purely client-side and do not trigger on these server-side events.
• Access to Old Value: If your logic needs to compare the current field value with its previous value (e.g., to detect a change from “Open” to “Closed”), a Client Script is necessary as UI Policies do not inherently provide this “old value” context.

Troubleshooting Common UI Policy Issues

Even with their relative simplicity, UI Policies can sometimes present challenges. Here are a few common issues and how to tackle them:

• UI Policy Not Firing:
  • Check “Active” status: Ensure the UI Policy is active.
  • Verify Conditions: Double-check the “Condition” field. Is it accurate? Are you using the correct field names and operators? Test with a simpler condition if necessary.
  • “On load” vs. Field Change: If you expect it to run on load but it’s not, ensure “On load” is checked. If it’s only supposed to run on field changes, ensure the field you’re changing is indeed part of the condition.
  • View Specificity: If the policy applies to a specific view, ensure you’re in that view.
  • Inheritance Issues: If using “Inherit,” confirm the table hierarchy is correct and the parent policy is configured as intended.
• UI Policy Actions Not Working as Expected:
  • “Reverse if false” setting: This is a frequent culprit. If actions aren’t reversing correctly, check this box. If you *don’t* want reversal, uncheck it.
  • “Leave alone” in Actions: Ensure you haven’t inadvertently set an attribute to “Leave alone” when you intended to change it.
  • Order of Evaluation: If multiple UI Policies or Client Scripts are acting on the same field, the “Order” field for UI Policies and the execution order of Client Scripts become critical. Remember, UI Policies run after Client Scripts.
  • Related List Actions: For related lists, confirm the “List name” is correct and that the “Visible” attribute is set as intended.
• Script Errors:
  • “Run scripts” enabled: Ensure the “Run scripts” checkbox is ticked in the Advanced view.
  • “Reverse if false” for “Execute if false” script: Crucial for the false script to run.
  • Platform Compatibility: Remember scripts might not run on mobile by default. Check the “Run scripts in UI type” setting.
  • GlideForm API Usage: Verify that you’re using the correct GlideForm API methods (e.g., `g_form.setValue()`, `g_form.setVisible()`, `g_form.setMandatory()`) and that the field names are accurate.
  • Browser Developer Console: Use your browser’s developer console (usually F12) to look for JavaScript errors. These often provide specific details about what went wrong.
• Performance Issues:
  • Excessive UI Policies/Scripts: Too many complex client-side scripts can slow down form loading. Review your policies for redundancy or opportunities for consolidation.
  • Complex Conditions: Very elaborate conditions can sometimes impact performance.

Interview Relevance

Understanding UI Policies is not just a development task; it’s a key indicator of a developer’s grasp of ServiceNow’s platform capabilities. In interviews, expect questions around:

• The difference between UI Policies and Client Scripts: Be prepared to articulate the key distinctions, including execution order, handling of form save events, and the ability to set field attributes without scripting.
• When to use a UI Policy over a Client Script (and vice versa): Demonstrate your ability to choose the most efficient and appropriate tool for a given task.
• Explaining the “Reverse if false” option: This is a fundamental UI Policy concept.
• Troubleshooting UI Policy behavior: Situational questions asking how you’d diagnose a UI Policy that isn’t firing or an action that isn’t being applied.
• The “Order” field and best practices for ordering.
• UI Policy Scripts and their limitations (e.g., platform specificity).

A solid understanding of UI Policies showcases your ability to build dynamic, responsive, and user-friendly applications within ServiceNow.

Conclusion

UI Policies are an indispensable tool in the ServiceNow developer’s arsenal. They empower you to create dynamic and intelligent forms with remarkable efficiency, often without the need for complex scripting. By mastering the creation, configuration, and nuances of UI Policy Actions and Scripts, you can significantly enhance the user experience of your applications, streamline workflows, and reduce development time.

Remember the practical tips, especially regarding the “Order” field and the judicious use of “Reverse if false,” and always keep the comparison with Client Scripts in mind to make informed architectural decisions. As you continue to build and refine applications on the ServiceNow platform, a deep understanding of UI Policies will undoubtedly contribute to your success.