What Exactly Are UI Policies? The Client-Side Magicians

Let’s start with the basics. What are UI Policies? Simply put, they are client-side logic that dictates how fields behave on a form. Think of them as traffic cops for your form fields, making them:

• Mandatory: Requiring user input before submission.
• Read-only: Displaying information without allowing changes.
• Hidden/Visible: Showing or hiding fields based on conditions.
• Controlling Related Lists: Displaying or hiding related lists dynamically.

The key phrase here is “client-side.” This means UI Policies execute directly in the user’s browser, providing an immediate and responsive experience. When a condition is met, the UI Policy springs into action, updating the form instantly without needing to talk back to the server. This makes them incredibly efficient for enhancing user experience.

Troubleshooting Tip: If you’re expecting a field to change visibility or become mandatory, but it’s not happening, always check for active UI Policies first. They often override other settings or even each other.

Diving Deeper: Key UI Policy Settings and Their Quirks

Understanding the various checkboxes and settings within a UI Policy is paramount to wielding its power effectively and, more importantly, troubleshooting it when things go awry. These little checkboxes pack a punch!

The “On Load” Conundrum: When Does It Actually Kick In?

The “On Load” checkbox is one of the most fundamental settings. When selected, the UI Policy’s conditions and actions are evaluated and applied immediately as soon as the form finishes loading in the browser. This is ideal for setting initial states for fields – for instance, making a ‘Resolution Notes’ field mandatory only if the ‘State’ is ‘Resolved’ when the form first appears.

Here’s the kicker: If “On Load” is not selected, the UI Policy will not apply its actions when the form initially loads. Instead, it waits for a specific field or condition to change on the form to trigger its evaluation. This can be a source of confusion.

Real-World Scenario & Troubleshooting: Imagine you want a ‘Comments’ field to be hidden by default unless a specific checkbox is ticked. If you create a UI Policy to hide ‘Comments’ when the checkbox is false, but forget to select “On Load,” the ‘Comments’ field will remain visible when the form first loads. It will only hide *after* you interact with another field or change the state of the checkbox. If you encounter this, your first stop should be the “On Load” checkbox.

The “Global” View: When to Limit Your Reach

The “Global” checkbox controls the scope of your UI Policy across different form views. When checked, your UI Policy will apply to all views of that form. This is the default and often desired behavior.

However, if you uncheck “Global,” you’ll be prompted to specify a particular ‘View’ name. In this case, your UI Policy will only activate when the form is displayed in that specific view. This offers immense flexibility for tailoring user experiences based on context – perhaps a simplified view for end-users and a more detailed one for IT staff.

Interview Insight: This is a classic interview question! Be ready to explain the implications of “Global” and why you might want to uncheck it. They want to see if you understand how to customize experiences for different user groups.

Troubleshooting: If your UI Policy isn’t firing, and you’ve already checked “On Load,” the “Global” setting is your next suspect. Could it be that your policy is set for a specific view, but the form you’re testing is in a different view (e.g., ‘Default’ vs. ‘Self Service’)? Always confirm the active view when troubleshooting view-specific issues.

“Reverse if false”: The Unsung Hero of Reversibility

This checkbox is incredibly important and often misunderstood. When “Reverse if false” is selected, any actions applied by the UI Policy when its condition evaluates to true will be automatically reversed when the condition evaluates to false.

Example: If your UI Policy makes a ‘Reason for Change’ field mandatory when ‘Change Type’ is ‘Emergency’, and “Reverse if false” is checked, then as soon as ‘Change Type’ is no longer ‘Emergency’, ‘Reason for Change’ will become optional again.

If “Reverse if false” is not selected, the UI Policy actions will only apply when the condition is true. Once the condition becomes false, the fields will retain their last state from when the condition was true. This means a field made mandatory might *stay* mandatory even if the conditions no longer warrant it.

Troubleshooting: If a field is stuck in a mandatory, read-only, or hidden state even after the conditions that triggered it are no longer met, this checkbox is almost certainly the culprit. Ensure “Reverse if false” is checked unless you have a very specific reason for the field to retain its state.

“Inherit”: Sharing the Love with Child Tables

The “Inherit” checkbox comes into play when you’re working with table hierarchies. When checked, the UI Policy will not only apply to the table it’s defined on but also to any tables that extend (or are “children” of) that table. This is a powerful way to enforce consistent form behavior across related tables without recreating the same policy multiple times.

Example: A UI Policy defined on the Task [task] table with “Inherit” checked will also apply to Incident [incident], Problem [problem], Change Request [change_request], etc., because these tables extend ‘Task’.

Troubleshooting: If you’re seeing unexpected UI behavior on an extended table, check the parent tables for inherited UI Policies. Sometimes, a policy on a parent table can conflict with or override a policy you’ve defined on the child table, leading to confusing results.

“Run scripts”: Unleashing Client-Side Power

While UI Policy actions cover common scenarios like making fields mandatory or visible, sometimes you need more complex client-side logic. That’s where the “Run scripts” checkbox comes in. When enabled, it allows you to write client-side JavaScript that executes when the UI Policy’s conditions are met.

You get two script boxes: “Execute if true” and “Execute if false.” This provides incredible flexibility to perform actions not available through standard UI Policy actions, such as:

• Displaying messages to the user.
• Manipulating non-field elements on the form.
• Calling GlideAjax for server-side lookups.
• Making complex calculations.

Interview Question: Can you write scripts in a UI Policy? Absolutely, and knowing how to enable “Run scripts” is the answer! Be prepared to give examples of when you might choose scripting over declarative actions.

Troubleshooting Scripted UI Policies: Scripting introduces a new layer of complexity. If your scripted UI Policy isn’t working:

1. Check Conditions First: Is the UI Policy actually firing? Put a simple alert() or console.log() in the “Execute if true” script to confirm.
2. Browser Console is Your Friend: Look for JavaScript errors in your browser’s developer console (F12). Typos, incorrect API calls, or undefined variables are common culprits.
3. Scope of Variables: Ensure any variables you’re referencing exist in the client-side scope.
4. Timing: Remember this is client-side. If you need server data, use GlideAjax.

UI Policies vs. Data Policies: The Great Debate and Conversion Conundrum

This is arguably one of the most frequently asked interview questions and a critical concept to grasp for any ServiceNow developer: What’s the difference between UI Policies and Data Policies?

Client-side vs. Server-side: A Fundamental Difference

1. UI Policy: Works exclusively on the client-side (in the user’s browser). It’s all about improving the user experience on the form.
2. Data Policy: Works on both the client-side and server-side. This is the fundamental difference. On the client, it enforces rules on the form. On the server, it enforces the same rules regardless of how the data is entered (e.g., import sets, web services, scripts, mobile apps).

Visibility vs. Integrity: Different Goals

This difference in execution location leads to different primary goals:

• UI Policy: Primarily concerned with form visibility and user interaction. It can hide fields, make them read-only, or mandatory.
• Data Policy: Primarily concerned with data integrity and consistency. It can make fields mandatory or read-only, but it cannot hide fields on the form. Why? Because a server-side rule can’t decide what’s visible in a browser.

Scripting and Views: Flexibility vs. Strictness

• UI Policy: Highly flexible. You can write scripts (client-side) and apply them to specific views.
• Data Policy: More rigid in its enforcement. You cannot write scripts within a Data Policy, and they cannot be applied to specific views (they work globally across all views to ensure consistent data input).

Works on All Sources vs. Only Forms

• UI Policy: Only works on the form itself. Data entered through other means (like APIs) bypasses UI Policies.
• Data Policy: Works on all sources where data can be entered, ensuring consistency whether it’s via a form, import set, web service, or script.

Can You Convert a UI Policy to a Data Policy? Yes, But With Rules!

ServiceNow offers a convenient feature to convert a UI Policy into a Data Policy. This is useful when you realize that a UI Policy’s enforcement (e.g., making a field mandatory) also needs to be enforced server-side for data integrity.

However, there are crucial rules and limitations:

A UI Policy CANNOT be converted to a Data Policy if it is:

1. Controlling Data Visibility: If the UI Policy hides or shows fields. (Data Policies can’t hide fields).
2. Controlling Views: If the UI Policy is applied to a specific view (unchecking “Global”). (Data Policies apply globally, not view-specific).
3. Controlling Related Lists: If the UI Policy shows or hides related lists. (Data Policies don’t interact with UI elements like related lists).
4. Controlling Scripts: If the UI Policy has “Run scripts” enabled with client-side JavaScript. (Data Policies cannot contain scripts).

The Golden Rule for Conversion: A UI Policy can only be converted to a Data Policy if its sole purpose is to make fields mandatory or read-only, and it doesn’t involve view-specific settings, related lists, or client-side scripting.

Interview Relevance: Understanding these conversion rules demonstrates a deep understanding of both policy types and their underlying mechanisms. It shows you know when to use which tool for the job.

The Dance of Execution: UI Policies and Client Scripts

When multiple client-side scripts and policies are on a form, knowing their execution order is vital for troubleshooting unexpected behavior. It’s a classic case of “who runs first?”

The general order of execution for client-side scripts and policies (when they are of the same type and defined on the same table or an inherited table) is:

1. onload Client Scripts (ordered by ‘Order’ field)
2. onload UI Policies (ordered by ‘Order’ field)
3. onchange Client Scripts (ordered by ‘Order’ field)
4. onchange UI Policies (ordered by ‘Order’ field)
5. …and so on for other types like onsubmit.

Here’s the critical takeaway: Client Scripts run BEFORE UI Policies of the same type.

Troubleshooting Conflicts:

• UI Policy not taking effect? Check if an onload or onchange Client Script is overriding its behavior. For example, a Client Script might be setting a field to mandatory, and then a UI Policy tries to make it optional, but the Client Script already set its state.
• Unexpected field state? If a UI Policy is making a field read-only, but an onchange Client Script is then trying to write to it, you might get console errors or inconsistent behavior.
• Order Matters: Both Client Scripts and UI Policies have an ‘Order’ field. If you have multiple scripts/policies of the same type (e.g., two onload UI Policies), the one with the lower ‘Order’ value will execute first. Leverage this to control priority in complex scenarios.

Best Practice: Whenever possible, use UI Policies for simple mandatory/read-only/visibility requirements. Resort to Client Scripts only when you need more complex logic. This makes forms easier to maintain and troubleshoot.

Catalog UI Policies: A Specialized Tool for the Service Catalog

The Service Catalog is a beast of its own, and it comes with its own flavor of UI Policies: Catalog UI Policies. While similar in concept to normal UI Policies, they have distinct characteristics:

Normal UI Policy vs. Catalog UI Policy: Key Differences

1. Scope of Application:
   • Normal UI Policy: Works on standard forms (e.g., Incident, Problem, Change). Can be applied to specific views.
   • Catalog UI Policy: Works specifically on Catalog Item forms, Requested Item (RITM) forms, and Catalog Task (SCTASK) forms. Crucially, it does not control views.
2. View Control: Normal UI Policies have the “Global” checkbox and can be view-specific. Catalog UI Policies do not offer view-specific control because catalog items typically don’t have multiple named views in the same way standard forms do.
3. Target Application: Catalog UI Policies have specific checkboxes to determine where they apply:
   • Applies on a Catalog Item
   • Applies on Requested Item
   • Applies on Catalog Task
   • Applies on Target Record (for Record Producers)

Targeting Record Producers and Catalog Tasks

This is where Catalog UI Policies get particularly interesting:

• Making a UI Policy work only on a Record Producer: For a Catalog UI Policy to apply specifically when a user is filling out a Record Producer (before the record is created), you should select only the “Applies on Target Record” checkbox. This ensures the policy’s actions only impact the target record’s form fields.
• Making a UI Policy work only on Catalog Tasks: If you want a Catalog UI Policy to apply specifically to the Catalog Task form (SCTASK), you should select only the “Applies on Catalog Task” checkbox.
• Making a UI Policy work only on the Catalog Item form: You would select only the “Applies on a Catalog Item” checkbox.

Troubleshooting Catalog UI Policies: If your catalog item fields aren’t behaving as expected, remember that you’re dealing with Catalog UI Policies, not standard ones. Check their specific ‘Applies On’ checkboxes to ensure they are targeting the correct stage of the request fulfillment process (item form, RITM, or SCTASK).

Advanced Scenarios: Calling UI Pages and GlideModalForm

While UI Policies are primarily for form field manipulation, they can also be part of a larger client-side strategy. It’s good to know that in client-side scripts (which can be triggered by UI Policies via the “Run scripts” option), you have the power to call other client-side components:

• UI Pages: Yes, you can call UI Pages from client scripts within UI Policies. This allows you to open custom pop-ups, interactive forms, or informational displays, leveraging the power of UI Pages for complex user interactions.
• GlideModalForm: This powerful client-side API is specifically used to open a record form (for a table) as a modal pop-up. So, if your UI Policy’s script needs to, for example, open a new ‘Task’ record in a modal window based on user input, GlideModalForm is your friend.

These capabilities, when combined with the “Run scripts” option, make UI Policies incredibly versatile for creating rich, interactive client-side experiences.

Consolidated Troubleshooting Scenarios for UI Policies

Let’s bring all the troubleshooting wisdom together for those head-scratching moments.

1. UI Policy Not Firing At All

• Are Conditions Met? Double-check your conditions. Are they accurately reflecting the state you expect? Use `gs.log()` for server-side conditions (if applicable in related server scripts) or `console.log()` in scripted UI policies to debug condition evaluation.
• “On Load” Checked? If you expect immediate action upon form load, ensure “On Load” is checked.
• Is it a View Issue? If “Global” is unchecked, is the UI Policy set for the correct view that you’re currently in?
• Active and Order: Is the UI Policy active? Is its ‘Order’ low enough if there are competing policies?
• Table Scope: Is it on the correct table, or an inherited table (if “Inherit” is checked)?

2. Unexpected Field Behavior (Stuck Read-Only, Not Mandatory, etc.)

• “Reverse if false”? If a field is stuck in a state even after conditions change, this checkbox is almost always the answer.
• Conflicting UI Policies: Are there other UI Policies on the same form (or parent tables) that are conflicting? Higher-ordered UI Policies might be overriding lower-ordered ones.
• Client Script Interference: An onload or onchange Client Script might be setting the field state and overriding your UI Policy. Remember, Client Scripts run before UI Policies.
• Data Policy vs. UI Policy: A Data Policy (which runs server-side) making a field mandatory will always win over a UI Policy trying to make it optional.

3. Scripted UI Policy Issues

• Browser Console: This is your best friend. Look for errors, warnings, and log messages.
• console.log() Debugging: Sprinkle `console.log()` statements throughout your script to trace execution flow and variable values.
• API Correctness: Are you using GlideForm (g_form) and other client-side APIs correctly?
• Condition Check: Is the script even being executed? Verify the UI Policy’s conditions are met.

4. Performance Considerations

While UI Policies are efficient, too many complex ones on a single form can impact load times. If forms are slow:

• Consolidate: Can multiple simple UI Policies be combined into one with more complex conditions?
• Simplify Conditions: Are conditions overly complex? Can they be simplified?
• Script Efficiency: If you’re using “Run scripts,” ensure your JavaScript is optimized and not performing unnecessary DOM manipulations or heavy calculations.