Unpacking UI Policies: Your Client-Side Form Butler

Imagine your ServiceNow form has a personal butler, always ready to react to user actions and present information in the most appropriate way. That’s essentially what a UI Policy is. It’s a client-side scriptless logic that dictates how fields behave on a form based on specific conditions.

What is a UI Policy?

At its core, a UI Policy is a set of rules applied to a form, designed to enhance the user experience and guide data entry. When certain conditions are met, a UI Policy can dynamically:

• Make a field mandatory: Ensuring users provide crucial information before saving.
• Make a field read-only: Preventing users from altering sensitive or already confirmed data.
• Show or hide a field: Displaying only relevant fields to the user, reducing clutter and complexity. This is often referred to as ‘display’ control.
• Show or hide related lists: Dynamically displaying additional information relevant to the current record.

The key takeaway here is “client-side” (Reference 58). This means UI Policies execute in the user’s browser, reacting instantly to their input without needing to communicate with the server. This makes them incredibly fast and responsive, perfect for improving the interactive experience of your forms.

Key Controls and Nuances of UI Policies

UI Policies come with several configurable options that give you fine-grained control over their behavior:

The “On Load” Checkbox

When you tick the “On Load” checkbox (Reference 61), your UI Policy swings into action the moment the form loads. Its conditions are evaluated, and actions are applied immediately. Think of it as the butler tidying up the room before the guest even sits down.

If “On Load” is unchecked, the UI Policy waits patiently. It will only trigger its actions when a specific field on the form is changed, and that change causes the policy’s conditions to be met. This is useful for policies that don’t need to be applied initially but react to subsequent user interactions.

“Reverse if false”: The Unwind Button

The “Reverse if false” checkbox (Reference 60) is a brilliant time-saver. If selected, when the UI Policy’s condition changes from true to false, any actions it applied are automatically reversed. For example, if a field was made mandatory when the condition was true, it will gracefully become optional again when the condition is false. This prevents you from needing to create a separate “opposite” UI Policy for the false scenario, making your policies cleaner and easier to manage.

“Global” Checkbox: View-Specific Control

The “Global” checkbox (Reference 59) dictates whether your UI Policy applies to all form views or just a specific one. If checked, the policy is active across all views for that table. If unchecked, you’ll be prompted to specify a particular view name, and the policy will then only apply when users are interacting with that specific view.

This is incredibly powerful for tailoring user experiences. For instance, an “ITIL View” might show different fields or related lists compared to a “Self-Service View” for the same record.

“Inherit” Checkbox: Extending Reach to Child Tables

The “Inherit” checkbox (Reference 62) allows your UI Policy to be applied not just to the table it’s defined on, but also to any tables that extend it (its child tables). This is a cornerstone of ServiceNow’s platform architecture, allowing you to define a rule once and have it cascade down to specialized tables. For example, a UI Policy on the Task table could apply to both Incident and Change records if “Inherit” is checked.

Scripting in UI Policies: When Conditions Aren’t Enough

While UI Policies are primarily scriptless, there are times when complex logic is required that cannot be achieved with simple condition builders. In such cases, you can write scripts within a UI Policy (Reference 63). To do this, you simply enable the “Run scripts” checkbox. This opens up two script fields: “Execute if true” and “Execute if false.” Here, you can write client-side JavaScript to perform more intricate actions.

Practical Scenario: Imagine needing to hide a field only if a user belongs to a specific group AND a date field is in the past. While some of this might be possible with conditions, the “Run scripts” option provides maximum flexibility. However, it’s a best practice to use scripts only when declarative conditions aren’t sufficient, as scripts are harder to maintain and troubleshoot.

Real-World UI Policy Scenarios

Let’s illustrate with some everyday examples:

• Incident Resolution: When an Incident’s state changes to “Resolved,” a UI Policy can make the “Resolution Notes” and “Resolution Code” fields mandatory and read-only. This ensures all resolved incidents have the necessary documentation.
• VIP User Information: If a user is marked as “VIP,” a UI Policy could dynamically display a “VIP Status Reason” field and make it mandatory, while hiding it for non-VIP users.
• Service Request Options: For a Service Catalog item, based on the selected “Request Type,” a UI Policy might hide or show different sets of variable fields, streamlining the request form for the user.

Troubleshooting UI Policies

UI Policies are generally robust, but issues can arise:

• Policy Not Firing: Double-check your conditions. Are they precise? Is the “On Load” checkbox correctly configured?
• Unexpected Behavior: If a field is behaving oddly (e.g., becoming read-only when it shouldn’t), inspect your active UI Policies on that table. Multiple policies might be conflicting.
• View-Specific Issues: Remember the “Global” checkbox. If a policy isn’t working in a specific view, verify if it’s set to “Global” or specifically enabled for that view.
• Order of Execution: This is crucial. When a form loads or changes, Display Business Rules run first, followed by Client Scripts, and finally UI Policies (Reference 73, 262). If a Client Script is making a field read-only, and a UI Policy is trying to make it editable, the UI Policy might win if it runs later. Always consider this order when debugging.
• Script Errors: If you’re using “Run scripts,” check the browser’s developer console (F12) for JavaScript errors.

Understanding Data Policies: The System’s Data Integrity Guardian

While UI Policies are concerned with the user experience on forms, Data Policies are the guardians of data integrity across your entire ServiceNow instance. They don’t care how data gets into the system; they just ensure it adheres to predefined rules.

What is a Data Policy?

Data Policies are rules that enforce data consistency and integrity regardless of the data source. They operate at both the client and server side (Reference 66), meaning their rules are enforced even if a form isn’t involved.

Data Policies can:

• Make a field mandatory: Ensuring critical data is always provided.
• Make a field read-only: Protecting data from unauthorized or accidental modification.
• Control field ‘display’: While UI Policies can hide fields dynamically, Data Policies mainly control the inherent presence or absence of a field based on conditions, often tied to their mandatory/read-only status. They don’t dynamically hide/show fields on forms in the same user-interactive way UI Policies do (Reference 67.2).

Think of a Data Policy as a strict bouncer at every entrance to your data store. Whether data comes through a front door (a form), a back alley (an import set), or a side window (a web service), the bouncer checks it.

The “All Data Sources” Power

This is where Data Policies truly shine. Their influence extends beyond just forms. They apply rules to all data entered into the system (Reference 66, 269), including:

• Data entered via standard ServiceNow forms.
• Data brought in through import sets (e.g., uploading a CSV file).
• Data updated or created via web services (e.g., REST APIs, SOAP integrations).
• Data entered through the mobile UI.
• Data modified by script (e.g., Business Rules, Fix Scripts).

Practical Scenario: Consider a situation where “Resolution Code” and “Notes” must be mandatory whenever an Incident’s state is “Resolved.” If a user resolves an incident via the standard form, a UI Policy might handle this. However, what if an external monitoring system resolves an incident via a web service? Or an administrator uses an import set to resolve multiple incidents? A UI Policy would be useless here. A Data Policy, however, would ensure that the “Resolution Code” and “Notes” are mandatory, enforcing data integrity regardless of the source (Reference 269).

Limitations and Key Differences

To understand Data Policies fully, it’s helpful to highlight what they don’t do, especially when compared to UI Policies:

• No Hiding Fields on Forms: Data Policies cannot hide a field on a form (Reference 67.2). They can make it mandatory or read-only, but the field will always be visible if it’s part of the form layout. This makes sense; if a field is critical for data integrity, it needs to be present for any data source, not just hidden away on a form.
• No Scripting: You cannot write scripts directly within a Data Policy (Reference 67.3). Data Policies are purely declarative; you define conditions and actions using the standard builder. This makes them simpler to configure and inherently more performant and secure.
• No View Specificity: Data Policies apply globally to a table; you cannot make a Data Policy specific to a particular view (Reference 67.4). Again, this aligns with their role as data integrity guardians – a data rule should apply consistently everywhere.
• No Control Over Related Lists: Data Policies do not have the capability to control the visibility or behavior of related lists (Reference 65, 270). This is purely a UI Policy function aimed at form presentation.
• Impacted by UI Policies: While Data Policies enforce rules at a system level, UI Policies (which run on the client) can sometimes seemingly override Data Policies on the form. For example, if a Data Policy makes a field mandatory, but a UI Policy makes it read-only, the field will appear read-only on the form. However, the *underlying data policy* will still enforce the mandatory rule during server-side processing if the field becomes editable and then saved without a value. This can lead to validation errors upon submission.

Troubleshooting Data Policies

When a Data Policy isn’t behaving as expected:

• Check Conditions: Like UI Policies, ensure your conditions are correct and cover all necessary scenarios.
• Test All Data Sources: Don’t just test on a form. Try modifying the record via an import set, a REST API call (if you have the tools), or the mobile interface to confirm the policy is enforced everywhere.
• Conflicting Policies: Multiple Data Policies could be active on the same table. Review them to ensure they don’t contradict each other.
• Client-Side Override Illusion: If a field that should be mandatory by a Data Policy isn’t enforcing it on the form, check for a UI Policy or Client Script that might be making it optional or read-only on the client side. Remember, the Data Policy’s enforcement will still kick in during the server-side save operation.

UI Policy vs. Data Policy: The Ultimate Showdown

Now that we’ve explored each tool individually, let’s put them side-by-side to highlight their fundamental distinctions.

The Core Distinctions

Here’s a table summarizing the key differences, helping you quickly discern between the two:

When to Use Which

Choosing between a UI Policy and a Data Policy isn’t about one being “better” than the other; it’s about using the right tool for the right job. They often complement each other beautifully.

• Reach for a UI Policy when:
  • You need to improve the user experience on a specific form.
  • You need to dynamically show or hide fields or related lists based on user input.
  • Your logic is purely about form presentation and does not need to be enforced if data is entered through non-form methods.
  • You have complex client-side logic that requires scripting (though use sparingly).
  • You need different behaviors for different form views.

  Rule of thumb: If it’s about how the form looks and behaves for a human user, think UI Policy.

• Opt for a Data Policy when:
  • You need to ensure fundamental data integrity, regardless of how data enters the system.
  • A field must *always* be mandatory or read-only under certain conditions, even if updated via an import set, API, or script.
  • The rule needs to be enforced at both the client and server levels.
  • You need a straightforward, declarative rule without complex client-side scripting.

  Rule of thumb: If it’s about the data itself and its integrity, regardless of how it gets into the system, think Data Policy.

The “Conversion” Conundrum

A common question is whether you can convert a UI Policy into a Data Policy. The answer is yes, you can (Reference 64)! ServiceNow provides a convenient “Convert this as Data Policy” UI Action on UI Policy records.

However, there’s a significant catch, and it directly relates to the fundamental differences we’ve discussed. You can only convert a UI Policy into a Data Policy if the UI Policy does not (Reference 65, 270):

• Control data visibility (i.e., hide or show fields).
• Control specific views.
• Control related lists.
• Contain any scripts.

This limitation makes perfect sense. A Data Policy cannot hide fields, is not view-specific, doesn’t control related lists, and cannot run scripts. Therefore, a UI Policy that uses any of these features simply has no equivalent in the Data Policy world and cannot be converted. This conversion utility is mainly for simplifying the transition of simple mandatory/read-only rules from forms to system-wide enforcement.

Order of Operations: Who Runs First?

When a form loads or a field changes, multiple client-side elements might be vying for control. Understanding the order in which they execute is critical for predictable behavior and effective troubleshooting.

The Hierarchy

The general order of execution on the client-side is as follows:

1. Display Business Rules: These server-side rules run first, right after data is retrieved from the database and before the form is presented to the user. They often pre-populate scratchpad variables for client-side use (Reference 262).
2. Client Scripts: Next, any relevant Client Scripts (onLoad, onChange, onSubmit) execute. These can perform complex validations and manipulate form fields. (Reference 73)
3. UI Policies: Finally, UI Policies run. They apply their rules based on the current state of the form, potentially overriding actions taken by Client Scripts (Reference 73).

Data Policies operate differently. While they have a client-side component that mirrors server-side enforcement on forms, their true power lies in their server-side execution. They are evaluated and enforced whenever data is saved or modified in the database, regardless of whether a form interaction just occurred or if data came from another source. Their “client-side” presence is more about providing immediate feedback to the user on the form (e.g., a mandatory field being highlighted) before the server-side save.

Knowing this hierarchy is crucial. If a Client Script makes a field read-only, but a UI Policy running later makes it editable, the UI Policy’s action will take precedence on the form. Conversely, if a UI Policy sets a field to read-only, and a Client Script tries to make it editable, the UI Policy will likely win because it runs later on the client side, unless the Client Script specifically targets overriding the UI Policy (which is generally bad practice).

Interview Insights and Best Practices

Understanding UI and Data Policies is a frequent topic in ServiceNow interviews. Here’s what you should be ready for:

Interview Questions to Expect

• “What is the core difference between a UI Policy and a Data Policy?” (Focus on client vs. client/server, form vs. all sources).
• “When would you use a UI Policy versus a Data Policy?” (Provide practical scenarios).
• “Can you hide a field using a Data Policy?” (No).
• “Can you write a script in a Data Policy?” (No).
• “Which one runs first: Client Script or UI Policy?” (Client Script).
• “What are the limitations when converting a UI Policy to a Data Policy?” (Visibility, views, related lists, scripts).

Best Practices

• Prioritize Data Integrity: Always start by considering Data Policies for critical data integrity rules. If a field *must* be mandatory or read-only across all entry points, a Data Policy is your primary tool.
• Enhance with UI Policies: Once data integrity is ensured, use UI Policies to refine the user experience on forms. Use them for dynamic hiding/showing, specific view behaviors, and client-side usability improvements.
• Avoid Redundancy (where possible): If a Data Policy makes a field mandatory, you don’t *strictly* need a UI Policy to do the same on the form, as the Data Policy will enforce it client-side as well. However, UI Policies can provide more immediate, conditional feedback.
• Limit Scripting: In UI Policies, use the condition builder as much as possible before resorting to “Run scripts.” Declarative logic is easier to maintain and less prone to errors.
• Document Thoroughly: Clearly document the purpose and conditions of your UI and Data Policies. This helps future administrators understand and maintain them.
• Test Across Sources: For Data Policies, always test your rules by interacting with the data through various means – forms, import sets, and (if applicable) web services – to confirm consistent enforcement.