Stepping into a ServiceNow developer or administrator interview? Get ready to talk UI. While the platform boasts incredible capabilities for automating workflows and managing services, a significant part of its charm lies in how users interact with it – through the interface. That’s where UI Policies come into play. They’re the silent heroes making forms intuitive, guiding users, and ensuring data quality right on the client side.

In this comprehensive guide, we’re going to break down the top UI Policy interview questions. We won’t just give you the answers; we’ll dive deep into the ‘why’ and ‘how,’ offering practical explanations, real-world scenarios, and even some troubleshooting tips. By the end, you’ll not only be ready to ace those tricky UI Policy questions but also gain a deeper understanding of how to wield this powerful tool effectively in your ServiceNow instances.

Let’s unlock the secrets to a stellar user interface and impress your interviewers!

The Core of Form Control: Making Fields Behave

Question 1: In how many ways can we make a field mandatory or read-only in ServiceNow?

This is a fundamental question that tests your breadth of knowledge about form and data control. It’s not just about knowing UI Policies; it’s about understanding the hierarchy and choosing the right tool for the job. You can make a field mandatory or read-only in at least five primary ways within ServiceNow:

1. Dictionary Properties (Table.Field Dictionary Entry)

   What it is: This is the most foundational level. When you define a field in the dictionary, you can set properties like ‘Mandatory’ and ‘Read only’ directly on the field’s definition. These settings are inherent to the field itself.

   When to use: When a field should *always* be mandatory or read-only, irrespective of any conditions or views, for every record created in that table. Think of fields like ‘Number’ or ‘Created by’ which are typically read-only, or a ‘Short Description’ field that’s almost always mandatory for an Incident.

   Interview Relevance: Demonstrates understanding of the lowest, most persistent layer of field configuration.

2. Dictionary Overrides

   What it is: If a field is inherited from a parent table (e.g., ‘Description’ on the Incident table, inherited from Task), you can override its dictionary properties for the specific child table. This allows you to say, “For Incidents, this inherited field behaves differently.”

   When to use: When an inherited field needs to be mandatory or read-only on a specific child table, but not on its parent or other child tables. For instance, ‘Priority’ might be optional on the Task table but mandatory for Incidents.

   Interview Relevance: Shows awareness of inheritance and how to manage field behavior in a hierarchical table structure.

3. UI Policies

   What it is: These are client-side rules that dynamically change the behavior of form fields based on specific conditions. They can make fields mandatory, read-only, or visible/hidden. Crucially, they operate directly in the user’s browser.

   When to use: When field behavior needs to be dynamic based on user interaction or other field values on the form. For example, if a ‘Resolution Notes’ field should only become mandatory when the ‘State’ changes to ‘Resolved’.

   Interview Relevance: This is the core topic of the article, demonstrating practical, client-side control.

4. Data Policies

   What it is: Similar to UI Policies in their function, Data Policies enforce data consistency across all data entry points – UI, import sets, web services, etc. They operate on both the client and server side. If a Data Policy makes a field mandatory, it means it *must* have a value before being saved, regardless of how the data arrived.

   When to use: When data integrity is paramount, and a field must be mandatory or read-only regardless of the source of the data. For example, ensuring ‘Caller’ is always populated for an Incident, even if it’s created via integration.

   Interview Relevance: Highlights your understanding of the difference between client-side (UI Policy) and client-and-server-side (Data Policy) enforcement, and data integrity.

5. Client Scripts (g_form.setMandatory(), g_form.setReadOnly())

   What it is: Client Scripts allow you to write JavaScript that executes in the user’s browser, giving you the most granular control over form behavior. The g_form API provides methods to manipulate field properties directly.

   When to use: When the logic for making a field mandatory or read-only is too complex for UI Policy conditions, or requires interaction with other elements or advanced JavaScript. For instance, making a field mandatory based on a calculation involving multiple fields or external data.

   Interview Relevance: Shows advanced knowledge of client-side scripting and an understanding of when UI Policies might not be sufficient.

Hierarchy and Best Practices:

It’s crucial to understand that these methods operate in a certain hierarchy. Generally, server-side mechanisms (Dictionary, Data Policies) take precedence over client-side ones (UI Policies, Client Scripts). Within client-side, a more specific rule (like a Client Script) might override a more general one. For mandatory fields, if any rule makes it mandatory, it will be mandatory. For read-only, if any rule makes it read-only, it will be read-only. Always start with the simplest, most declarative method (Dictionary) and move towards more complex, conditional methods (UI Policies, Client Scripts) only when necessary.

Understanding UI Policies: The Client-Side Enforcer

Question 2: What are UI Policies?

UI Policies are a powerful feature in ServiceNow that allows administrators and developers to dynamically change the behavior of form fields and form sections on the client side (i.e., in the user’s web browser). They are essentially client-side rules that execute when a form loads or when specified conditions on the form are met.

Their primary purposes include:

• Making fields Mandatory: Ensuring users provide necessary information before saving a record.
• Making fields Read-Only: Preventing users from altering certain data points once a condition is met.
• Showing or Hiding fields: Displaying only relevant fields to the user, reducing clutter and improving focus.
• Showing or Hiding Related Lists: Dynamically displaying related information based on the record’s context.

Think of them as dynamic form logic that responds to user input and record states, creating a more tailored and intuitive user experience. Unlike Client Scripts, UI Policies are configured declaratively (point-and-click), making them easier to manage for common scenarios.

Interview Relevance: This is your foundational answer. Be clear and concise, highlighting their client-side nature and core functionalities.

Unpacking Key UI Policy Checkboxes

Question 3: What is the ‘Global’ checkbox in UI Policies?

The ‘Global’ checkbox in a UI Policy dictates whether the policy applies across all views of a form or to a specific view. This seemingly small checkbox has a significant impact on user experience and configuration management.

• When ‘Global’ is checked: The UI Policy’s conditions and actions will apply to the form regardless of which view the user is currently seeing. This is the default and most common setting.

  Example: You want to make the ‘Short Description’ field mandatory for all Incidents, no matter if the user is in the ‘Default View’, ‘ITIL View’, or a custom ‘Service Desk View’. In this case, you’d leave ‘Global’ checked.

• When ‘Global’ is unchecked: The UI Policy will *only* apply to a specific view that you then explicitly select. When you uncheck ‘Global’, a ‘View’ field will appear, prompting you to choose the desired view.

  Example: Your ‘ITIL View’ for Incidents is highly streamlined, and you want to hide a specific ‘Internal Notes’ field only in this view, while it remains visible in the ‘Default View’. You would uncheck ‘Global’ and select ‘ITIL View’ in the ‘View’ field.

Troubleshooting Tip: If your UI Policy isn’t behaving as expected on a particular form, first check if ‘Global’ is selected or if the correct ‘View’ is specified. It’s a common oversight, especially with forms having multiple custom views.

Interview Relevance: Demonstrates understanding of how UI Policies interact with ServiceNow views, a critical aspect for tailoring user experiences for different roles or processes.

Question 4: What is ‘Reverse if false’ in UI Policies?

The ‘Reverse if false’ checkbox is one of the most powerful and often misunderstood features of UI Policies. It controls what happens to the fields affected by the UI Policy when its conditions are no longer met.

• When ‘Reverse if false’ is checked (Recommended Default): If the conditions for your UI Policy evaluate to ‘true’, the specified actions (e.g., make field mandatory, read-only, visible) are applied. When those conditions later evaluate to ‘false’ (e.g., a field value changes), the actions are automatically reversed. The fields revert to their state *before* the UI Policy applied its changes.

  Example: You have a UI Policy: “If ‘Category’ is ‘Hardware’, make ‘Asset Tag’ mandatory.”

  • User selects ‘Hardware’ for ‘Category’ -> ‘Asset Tag’ becomes mandatory.
  • User then changes ‘Category’ to ‘Software’ -> ‘Asset Tag’ automatically reverts to optional.

  This ensures a clean, dynamic, and intuitive user experience.

• When ‘Reverse if false’ is unchecked: If the conditions evaluate to ‘true’, the actions are applied. However, if the conditions later become ‘false’, the actions are *not* automatically reversed. The fields retain the state that the UI Policy imposed.

  Example: Using the same UI Policy above, but with ‘Reverse if false’ unchecked:

  • User selects ‘Hardware’ for ‘Category’ -> ‘Asset Tag’ becomes mandatory.
  • User then changes ‘Category’ to ‘Software’ -> ‘Asset Tag’ *remains mandatory* (unless another UI Policy or Client Script explicitly makes it optional).

When to uncheck ‘Reverse if false’: It’s a rare scenario, primarily when you want a “one-way” change. For instance, if a field becomes mandatory once a record reaches a certain state, and you want it to *stay* mandatory even if the state changes back. However, this can lead to unexpected behavior and a less user-friendly experience, so it should be used with extreme caution and clear justification.

Interview Relevance: Crucial for demonstrating a deep understanding of UI Policy dynamics and how to prevent unintended lingering effects on forms. This is a common point of confusion for new developers.

Question 5: What is the ‘On Load’ checkbox in UI Policy?

The ‘On Load’ checkbox determines whether a UI Policy’s conditions are evaluated and its actions are applied immediately when a form initially loads in the browser.

• When ‘On Load’ is checked (Recommended Default): The UI Policy conditions are evaluated, and actions are applied as soon as the form loads. This is essential for setting the initial state of fields based on the record’s existing data.

  Example: You have a UI Policy to hide the ‘Resolution Notes’ field if the ‘State’ is not ‘Resolved’. If ‘On Load’ is checked, when an existing Incident record with ‘State’ = ‘New’ is opened, ‘Resolution Notes’ will be hidden immediately upon loading the form.

• When ‘On Load’ is unchecked: The UI Policy’s conditions and actions will *not* be applied when the form initially loads. Instead, the actions will only be triggered when a field on the form changes that impacts the UI Policy’s conditions.

  Example: Using the same policy, if ‘On Load’ is unchecked and you open an Incident with ‘State’ = ‘New’, ‘Resolution Notes’ will be visible. It will only become hidden if you *then* change the ‘State’ field to ‘Resolved’ (or whatever condition triggers the hide action), and then change it *back* to ‘New’. This can lead to an inconsistent initial form state.

When to uncheck ‘On Load’: Very rarely. One niche scenario might be if you have a computationally intensive UI Policy or script that you only want to run after a specific user interaction, not on every form load. However, for most dynamic form behavior, ‘On Load’ should be checked to ensure the form displays correctly from the start.

Troubleshooting Tip: If your form fields aren’t showing up correctly when a record is first opened, but then react fine after you change a field, chances are you forgot to check ‘On Load’ on the relevant UI Policy.

Interview Relevance: Demonstrates understanding of form rendering and initial state management. It’s about ensuring the user sees the correct form layout from the very beginning.

Question 6: What is the ‘Inherit’ checkbox in UI Policy?

The ‘Inherit’ checkbox comes into play when you’re working with table hierarchies in ServiceNow (e.g., the Task table and its child tables like Incident, Problem, Change).

• When ‘Inherit’ is checked (Recommended Default): If you create a UI Policy on a parent table (e.g., the ‘Task’ table) and check ‘Inherit’, that UI Policy will also apply to all tables that extend the parent table (e.g., ‘Incident’, ‘Problem’, ‘Change Request’, ‘Request Item’). This is a powerful way to enforce consistent UI behavior across related tables without recreating the policy multiple times.

  Example: You want to make the ‘Short Description’ field read-only for all completed tasks across the platform. You create a UI Policy on the ‘Task’ table: “If ‘State’ is ‘Closed’, make ‘Short Description’ read-only.” With ‘Inherit’ checked, this policy will automatically apply to Incidents, Problems, Changes, etc., when their state is ‘Closed’.

• When ‘Inherit’ is unchecked: The UI Policy will *only* apply to the specific table on which it was created. It will not apply to any child tables extending that table.

  Example: You create a UI Policy on the ‘Task’ table to hide a custom field specific to tasks that are *not* Incidents or Problems. In this case, you would uncheck ‘Inherit’ to prevent the policy from affecting the child tables, ensuring it only runs on the base ‘Task’ table or other custom task extensions where you want it.

Interview Relevance: Tests your understanding of table inheritance and how to manage UI consistency (or create exceptions) across a table hierarchy, a common architectural pattern in ServiceNow.

Beyond Declarative: Scripting in UI Policies

Question 7: Can you write a script in a UI Policy?

Yes, absolutely! While UI Policies are primarily designed for declarative (point-and-click) configuration, ServiceNow provides the flexibility to extend their functionality with client-side JavaScript. This bridge between declarative and imperative logic makes UI Policies incredibly versatile.

How to enable scripting:

1. When creating or editing a UI Policy, you’ll see a checkbox labeled “Run scripts”.
2. Check this box.
3. Two new script fields will appear: “Execute if true” and “Execute if false”.

What you can do with scripts:

• Complex Field Manipulation: Perform actions that are not available through the standard UI Policy actions, such as setting field values dynamically (g_form.setValue()), clearing values (g_form.clearValue()), or adding messages (g_form.addInfoMessage(), g_form.showFieldMsg()).
• Interaction with UI Elements: Manipulate elements beyond standard fields, though this is often discouraged due to potential upgrade issues.
• Advanced Logic: Implement conditions that are too complex for the standard condition builder (e.g., checking multiple values across different fields, performing calculations, or interacting with user preferences).

Example (Execute if true script): Let’s say you have a UI Policy that makes the ‘Approval Reason’ field visible if the ‘Approval Status’ is ‘Rejected’. In the ‘Execute if true’ script, you might also want to set a default message or dynamically adjust another field:

function onCondition() {
    g_form.setValue('u_approval_reason', 'Please provide detailed rejection notes.');
    g_form.addErrorMessage('Approval was rejected. Provide reason.');
}

Best Practice / When to use Client Scripts instead: While you can write scripts in UI Policies, it’s generally considered best practice to use a dedicated Client Script (e.g., an `onChange` or `onSubmit` script) if your logic becomes significantly complex or if you need to perform actions that aren’t directly tied to a UI Policy’s condition-action paradigm. UI Policy scripts are best for small, contained pieces of logic directly complementing the declarative actions of the policy.

Interview Relevance: Shows your understanding of extending declarative functionality with code, and your awareness of the `g_form` API, which is central to client-side scripting in ServiceNow.

UI Policies vs. Data Policies: The Great Distinction

Question 8: Can we convert a UI Policy into a Data Policy?

Yes, in many cases, you absolutely can! ServiceNow provides a convenient way to convert an existing UI Policy into a Data Policy. This is particularly useful when you’ve developed a UI Policy to enforce data consistency on the form, and you then realize that the same consistency needs to be enforced across *all* data entry points (imports, APIs, etc.).

How to convert:

1. Navigate to the UI Policy you wish to convert.
2. Open the UI Policy record.
3. On the form header, you’ll find a related link or button (often under “Related Links” or a context menu) labeled “Convert to Data Policy”.
4. Clicking this will create a new Data Policy with the same conditions and field actions (mandatory/read-only) as the original UI Policy.

Why convert? It saves time and ensures consistent data enforcement. If you initially built a UI Policy to make a field mandatory on the form, and then requirements change to make it mandatory for *all* data entries, converting saves you from recreating the logic from scratch. It also helps in migrating towards a more robust, server-side data integrity strategy.

Interview Relevance: Demonstrates practical knowledge of platform features and an understanding of how to transition between client-side and server-side data enforcement strategies efficiently.

Question 9: Which cases prevent a UI Policy from being converted to a Data Policy?

While conversion is handy, not every UI Policy can or should be converted. Data Policies have a different scope and purpose, primarily focused on server-side data integrity. Therefore, any UI Policy actions that are purely client-side UI manipulations cannot be replicated by a Data Policy.

Here are the cases where a UI Policy cannot be converted (or the conversion would not carry over the relevant actions):

• When you are controlling data visibility (Show/Hide Field)

  Explanation: UI Policies can hide or show fields on a form. Data Policies, however, are concerned with the *data* itself and its integrity, not how it’s presented on the UI. They don’t have the concept of “showing” or “hiding” a field from a user. If a field is hidden by a UI Policy, it simply means it’s not displayed on the form, but the data still exists and can be manipulated by other means.

• When you are controlling form views

  Explanation: This refers to the ‘Global’ checkbox on a UI Policy, which determines if the policy applies to all views or a specific one. Data Policies enforce rules regardless of the view. They operate at a deeper level, unaffected by how the UI is laid out.

• When you are controlling related lists (Show/Hide Related List)

  Explanation: UI Policies can dynamically show or hide entire related lists based on form conditions. Similar to individual fields, related lists are purely a UI construct. Data Policies have no mechanism to control the visibility of related lists because they operate on the data model, not the presentation layer.

• When you are controlling scripts (Execute if true/false scripts)

  Explanation: If your UI Policy utilizes the “Run scripts” option, the JavaScript contained within those scripts (Execute if true / Execute if false) is client-side code. Data Policies, while enforcing rules on both client and server, do not execute arbitrary client-side JavaScript. Any complex logic or `g_form` manipulations within UI Policy scripts would not transfer to a Data Policy.

Key takeaway: If a UI Policy performs actions purely related to how the form *looks* or *behaves* in the browser, it cannot be fully converted to a Data Policy. Only the mandatory and read-only aspects that directly affect data persistence are convertible.

Interview Relevance: This question directly probes your understanding of the fundamental difference in scope between UI Policies (client-side UI presentation) and Data Policies (client/server-side data integrity).

Question 10: What are Data Policies?

Data Policies are a critical feature in ServiceNow for enforcing data consistency and integrity across all data entry points. While UI Policies focus on the client-side user experience, Data Policies take a broader, more robust approach.

Key characteristics of Data Policies:

• Enforce Mandatory/Read-Only/Visibility: Just like UI Policies, Data Policies can make fields mandatory, read-only, or visible/hidden. However, their enforcement goes beyond just the form.

• Works from all data sources: This is the crucial distinction. Data Policies apply their rules not only when a user interacts with a form but also when data is entered or updated through:

  • Import Sets
  • Web Services (APIs)
  • REST/SOAP integrations
  • Mobile applications
  • ServiceNow Studio (scripted changes)

• Works at both client and server side: When a user submits a form, the Data Policy is first evaluated client-side (providing immediate feedback). More importantly, it’s *also* evaluated server-side when the record is saved. This server-side enforcement ensures that data consistency rules cannot be bypassed, even by non-UI methods.

• Ensures Data Integrity: The primary goal of Data Policies is to maintain the quality and integrity of your instance’s data by ensuring essential fields are always populated or protected, regardless of how the data enters the system.

Example: You create a Data Policy that states: “The ‘Caller’ field on the Incident table is mandatory if the ‘State’ is ‘In Progress’.”

• If a user tries to save an Incident with ‘State’ = ‘In Progress’ and no ‘Caller’ on the form, they’ll immediately get a client-side warning.
• If an integration tries to update an Incident to ‘In Progress’ without providing a ‘Caller’, the update will fail at the server level, preventing data corruption.

Interview Relevance: This question allows you to demonstrate your understanding of data integrity, the difference between client-side and server-side enforcement, and the importance of platform-wide data governance.

Troubleshooting and Best Practices

Common UI Policy Troubleshooting Scenarios:

• Policy Not Firing:

  • Conditions Mismatch: Double-check your UI Policy conditions. Are they exactly what you expect? Test them with various field values.
  • ‘On Load’ Unchecked: If the policy only fires after a field change but not on initial load, ensure ‘On Load’ is checked.
  • ‘Global’ / View Issues: If it works on one view but not another, check the ‘Global’ checkbox and the specified ‘View’.
  • Order Field: If multiple UI Policies affect the same field, the ‘Order’ field determines precedence (lower number runs first). Conflicts can cause unexpected behavior.

• Policy Not Reverting:

  • ‘Reverse if false’ Unchecked: If actions persist even after conditions are no longer met, verify ‘Reverse if false’ is checked.

• Performance Issues:

  • Too Many Policies: A large number of complex UI Policies on a single form can impact load times. Consolidate where possible.
  • Complex Scripts: If you’re using ‘Run scripts’, ensure your JavaScript is optimized and efficient. Avoid excessive DOM manipulation.

Interview Relevance: Best Practices for UI Policies:

• Use Declarative First: Always opt for UI Policies over Client Scripts for mandatory, read-only, and visibility requirements when possible. They are easier to maintain and less prone to errors.
• Keep it Simple: Break down complex form logic into multiple, simpler UI Policies rather than one giant, convoluted one.
• Naming Conventions: Use clear and consistent naming conventions for your UI Policies (e.g., “INC_Hide_ResolutionNotes_If_New”).
• Order Matters: Be mindful of the ‘Order’ field, especially when multiple policies might affect the same fields.
• UI Policy vs. Data Policy: Understand when to use which. UI Policies for form-specific UI behavior, Data Policies for platform-wide data integrity.
• Test Thoroughly: Always test your UI Policies across different scenarios, views, and user roles to ensure they behave as expected.

Conclusion

UI Policies are more than just a configuration option; they are a cornerstone of building intuitive, efficient, and data-compliant user experiences in ServiceNow. By mastering the concepts discussed in this article – from the basic functionalities to the nuances of their checkboxes and the critical distinction from Data Policies – you’re not just preparing for an interview; you’re equipping yourself with essential skills for effective ServiceNow development.

Remember, a strong understanding of UI Policies demonstrates your ability to think about user experience, data integrity, and efficient platform configuration. Go forth, practice, and confidently conquer those ServiceNow interviews!