Understanding the Power of “On Load” in UI Policies

Before we dive into the exciting examples, let’s quickly recap what the “On Load” checkbox in a UI Policy truly means. As per ServiceNow’s core functionality, when you select the “On Load” checkbox:

The conditions and actions specified in the UI Policy are evaluated and applied immediately when the form is loaded. If the “On Load” checkbox is not selected, the UI Policy actions will not be applied when the form is initially loaded. Instead, the actions will only be triggered when a specific field or condition is met on the form.

Think of it as setting the initial scene for your users. When they first open a record, what should they see? What information is critical? What fields should be hidden or made mandatory based on the context? The “On Load” functionality empowers us to define this initial state, ensuring users are presented with a form tailored to their immediate needs.

This immediate application is crucial for several reasons:

• Reduced Clutter: Hiding irrelevant fields upfront prevents users from being overwhelmed.
• Improved Data Quality: Making fields mandatory based on initial conditions ensures essential data is captured from the start.
• Streamlined Workflows: Guiding users through the form by showing or hiding sections based on their role or the record’s state.
• Enhanced Performance: While not the primary purpose, judicious use can sometimes improve perceived performance by loading only what’s necessary.

Now, let’s get our hands dirty with some practical examples.

Example 1: Incident Management – Prioritizing Critical Information

In an Incident Management process, not all incidents are created equal. When an incident is reported, the initial priority and impact often dictate the urgency of the response. An “On Load” UI Policy can help us surface the most critical fields when a high-priority incident is detected.

Scenario: Automatically Make ‘Major Incident’ and ‘Major Incident Affected CIs’ Mandatory for P1 Incidents

Imagine a scenario where a P1 (Critical) incident is reported. In such cases, it’s vital to immediately identify if this is a ‘Major Incident’ and which Configuration Items (CIs) are affected. We want to ensure these fields are not just visible but also mandatory as soon as the P1 incident is loaded.

UI Policy Configuration:

• Name: P1 Incident – Make Major Incident Fields Mandatory
• Table: Incident [incident]
• Applies to a visible field: No (We want this to run on form load, regardless of field visibility changes)
• On Load: Checked
• Condition:
  • [Priority] [is] [1 - Critical]

UI Policy Actions:

• Action 1:
  • Field: Major Incident
  • Visible: True
  • Mandatory: True
• Action 2:
  • Field: Major Incident Affected CIs
  • Visible: True
  • Mandatory: True

Explanation and Real-World Impact:

When a user creates or opens an Incident record, if the ‘Priority’ field is set to ‘1 – Critical’, this UI Policy will immediately execute. It will ensure that the ‘Major Incident’ checkbox is visible (if it wasn’t already) and, more importantly, make it mandatory. The same applies to the ‘Major Incident Affected CIs’ field. This ensures that the support team, upon seeing a critical incident, is immediately prompted to identify if it’s a major incident and to specify the affected CIs, which is crucial for effective incident resolution and communication.

This is far more effective than relying on a user to remember to fill in these fields or triggering it only on a change event. The ‘On Load’ nature guarantees immediate adherence to critical data capture requirements.

Troubleshooting Tip:

If the policy isn’t working as expected:

• Double-check the exact ‘Value’ for ‘Priority 1 – Critical’ in your system. Field values can sometimes have subtle differences (e.g., ‘1 – Critical’ vs. ‘1 – P1’).
• Ensure the UI Policy is active.
• Clear your browser cache. Sometimes, old UI policy configurations can be cached.
• Check for conflicting UI Policies or Client Scripts that might be overriding these settings. Use the “Inspect” feature in your browser’s developer tools to see which scripts are running on the form.

Example 2: Change Management – Tailoring Change Request Forms

Change Management is a critical process in IT operations. The type of change often dictates the fields that are relevant. An “On Load” UI Policy can dynamically adjust the form to match the change type, making the process more efficient and less prone to errors.

Scenario: Hiding Implementation and Test Plan Fields for ‘Normal’ Changes, but Making Them Visible for ‘Emergency’ and ‘Standard’ Changes

In Change Management, ‘Normal’ changes typically have a well-defined, documented plan. ‘Emergency’ changes, by their nature, have less upfront documentation but require a clear understanding of implementation steps. ‘Standard’ changes are pre-approved and follow a defined script.

We want to hide the detailed ‘Implementation Plan’ and ‘Test Plan’ fields by default for ‘Normal’ changes because they might be linked to separate documents or tasks. However, for ‘Emergency’ and ‘Standard’ changes, we want these fields to be immediately visible and perhaps even mandatory to ensure proper tracking.

UI Policy Configuration:

• Name: Change Request – Hide/Show Implementation & Test Plan
• Table: Change Request [change_request]
• Applies to a visible field: No
• On Load: Checked
• Condition:
  • [Type] [is] [Normal]

UI Policy Actions:

• Action 1:
  • Field: Implementation Plan
  • Visible: False
  • Mandatory: False
• Action 2:
  • Field: Test Plan
  • Visible: False
  • Mandatory: False

Second UI Policy (or a separate UI Policy if preferred for clarity):

• Name: Change Request – Make Implementation & Test Plan Mandatory for Emergency/Standard
• Table: Change Request [change_request]
• Applies to a visible field: No
• On Load: Checked
• Condition:
  • [Type] [is one of] [Emergency, Standard]

UI Policy Actions (for the second UI Policy):

• Action 1:
  • Field: Implementation Plan
  • Visible: True
  • Mandatory: True
• Action 2:
  • Field: Test Plan
  • Visible: True
  • Mandatory: True

Explanation and Real-World Impact:

When a user selects ‘Normal’ as the Change Type, the first UI Policy fires on load, hiding the ‘Implementation Plan’ and ‘Test Plan’ fields. This declutters the form, as this information is likely managed elsewhere. Conversely, if the user selects ‘Emergency’ or ‘Standard’ as the Change Type, the second UI Policy kicks in, making these fields visible and mandatory. This ensures that for changes requiring direct planning input on the form, that input is captured immediately. The ‘On Load’ execution means the user sees the form correctly configured from the moment they open it, rather than waiting for a field change event.

Troubleshooting Tip:

For this specific example, consider the order of UI Policies. If you have multiple UI Policies affecting the same fields, the one with the higher order number (or the one that executes later in the sequence) might override others. You can adjust the ‘Order’ field on the UI Policy form.

Also, ensure the ‘Type’ field on the Change Request form uses consistent values. If ‘Standard’ is sometimes entered as ‘Standard Change’, your condition might fail. Using a choice list for the ‘Type’ field is highly recommended.

Example 3: Employee Onboarding – Dynamic Welcome and Tasks

Employee onboarding is a crucial first impression. A well-structured onboarding form can guide new hires and their managers through the necessary steps. “On Load” UI Policies are excellent for setting the initial state of an onboarding task or request.

Scenario: Showing Specific Welcome Text and Hiding ‘Manager Approval’ for Self-Service Initiated Onboarding

When an onboarding request is initiated directly by the new employee (self-service), we want to display a specific welcome message and perhaps hide or make optional certain manager approval fields until later in the process. This can make the initial steps feel more direct for the new hire.

UI Policy Configuration:

• Name: Onboarding – Self-Service Welcome & Approval
• Table: Employee Onboarding [u_employee_onboarding] (assuming a custom table)
• Applies to a visible field: No
• On Load: Checked
• Condition:
  • [Initiated By] [is] [New Hire]

UI Policy Actions:

• Action 1:
  • Field: Welcome Message
  • Visible: True
  • Value: “Welcome aboard! Please complete the following details to get started.” (Or use a Catalog Item variable if the message is dynamic)
• Action 2:
  • Field: Manager Approval
  • Visible: False
  • Mandatory: False
• Action 3:
  • Field: Department Head Approval
  • Visible: False
  • Mandatory: False

Explanation and Real-World Impact:

When a new hire initiates their onboarding through a self-service portal, this UI Policy will run on load. It will ensure a friendly ‘Welcome Message’ is visible, guiding them. Crucially, it will hide the ‘Manager Approval’ and ‘Department Head Approval’ fields. This is because, in a self-service scenario, the employee might fill out their initial details first, and approvals can be triggered later through an automated workflow or a separate UI Policy that runs when the record is submitted or updated by the manager.

This ‘On Load’ action provides an immediate, tailored experience for the new employee, making the onboarding process feel less bureaucratic from the outset.

Troubleshooting Tip:

If the ‘Welcome Message’ field isn’t a standard field on your onboarding table, you might need to use a UI Policy to make a specific HTML field or a read-only text field visible and set its value. For dynamic messages, consider using Client Scripts in conjunction with UI Policies if the message content needs to be more complex and derived from other fields.

If you find that the ‘Manager Approval’ field is still visible, ensure there isn’t another UI Policy or Client Script that is setting its visibility to ‘True’ or overriding your ‘False’ setting. Check the field’s default visibility and any other business rules that might interact with it.

Example 4: Problem Management – Hiding Resolution Details Until Problem is Resolved

Problem Management aims to find the root cause of recurring incidents and prevent future occurrences. The ‘Resolution Details’ should only be filled in once a root cause has been identified and a solution implemented. An “On Load” UI Policy can ensure this field is hidden until the appropriate stage.

Scenario: Hide ‘Resolution Details’ Field When Problem is Not in ‘Resolved’ or ‘Closed’ State

We want to keep the ‘Resolution Details’ field hidden from users unless the Problem record is in a state where the resolution has been documented.

UI Policy Configuration:

• Name: Problem Management – Hide Resolution Details
• Table: Problem [problem]
• Applies to a visible field: No
• On Load: Checked
• Condition:
  • [State] [is not] [Resolved]
  • AND
  • [State] [is not] [Closed]

UI Policy Actions:

• Action 1:
  • Field: Resolution Details
  • Visible: False
  • Mandatory: False

Explanation and Real-World Impact:

When a Problem record is opened, if its current ‘State’ is anything other than ‘Resolved’ or ‘Closed’ (e.g., ‘New’, ‘In Progress’, ‘On Hold’), this UI Policy will execute on load. It will hide the ‘Resolution Details’ field. This prevents users from accidentally or prematurely entering resolution information. The field will only become visible (and potentially mandatory if another UI Policy or business rule dictates it) when the state is changed to ‘Resolved’ or ‘Closed’. This maintains the integrity of the problem resolution documentation.

Troubleshooting Tip:

The ‘State’ field in Problem Management (and other task-based tables) is often managed by workflows. Ensure your UI Policy’s conditions align with the expected values of the ‘State’ field as defined in your workflow. If the workflow transitions the problem to a different state, and your UI Policy relies on a previous state, it might not behave as expected. Always test with records in various states.

Interview Relevance: Mastering the “On Load” Concept

In a ServiceNow administration or development interview, demonstrating a solid understanding of UI Policies, especially the “On Load” functionality, is crucial. Interviewers often probe this area to gauge your practical application of form customization.

Common Interview Questions and How to Answer Them:

• “When would you use an ‘On Load’ UI Policy versus a UI Policy that triggers on field change?”

  Answer: “I’d use ‘On Load’ for initial form setup – to hide irrelevant fields, make critical ones mandatory based on the initial context, or display default information as soon as the user opens the record. This ensures a clean and guided user experience from the get-go. A UI Policy triggering on field change is used for dynamic adjustments based on user input *after* the form has loaded, for example, showing dependent fields when a parent field is selected.”

• “Can you give me an example of a situation where an ‘On Load’ UI Policy is essential?”

  Answer: “Certainly. In Incident Management, if a P1 incident is logged, an ‘On Load’ UI Policy can immediately make the ‘Major Incident’ and ‘Affected CIs’ fields mandatory. This ensures that critical information is captured right at the start, without the user having to remember to fill it in, improving response times for high-priority issues.”

• “What are the potential pitfalls of using ‘On Load’ UI Policies?”

  Answer: “One pitfall is creating too many complex ‘On Load’ policies, which could impact initial form load performance. Another is not considering the order of execution if multiple UI Policies affect the same fields. Also, if conditions are too broad, they might unintentionally affect records they shouldn’t. Finally, users might see a flicker if the UI Policy actions are complex and take a moment to render after the initial form load, though this is less common with simple visibility or mandatory settings.”

• “How do UI Policies interact with Client Scripts and Business Rules?”

  Answer: “UI Policies are generally processed on the client-side (browser) and are a declarative way to handle form behavior. They run after Client Scripts that execute on load but before Client Scripts that execute on change. UI Policies are processed before Business Rules. For very complex logic or interactions that depend on server-side data, a Client Script might be necessary, often working in conjunction with a UI Policy or Business Rule.”

By being able to articulate these points with practical examples, you’ll demonstrate not just knowledge, but also the ability to apply that knowledge effectively in real-world scenarios.

Best Practices for OnLoad UI Policies

To ensure your UI Policies are effective and maintainable, keep these best practices in mind:

• Keep it Simple: Avoid overly complex conditions or too many actions in a single UI Policy. Break down complex logic into multiple, well-named policies.
• Descriptive Naming: Use clear and concise names that indicate the purpose of the UI Policy (e.g., “Incident – P1 Critical Fields Mandatory OnLoad”).
• Order Matters: Pay attention to the ‘Order’ field if multiple UI Policies affect the same fields. Ensure they execute in the intended sequence.
• Test Thoroughly: Always test your UI Policies across different user roles and record states to ensure they behave as expected without unintended side effects.
• Consider Performance: While ‘On Load’ policies are powerful, an excessive number of complex policies can impact initial form load times. Optimize where possible.
• Document Your Logic: Use the ‘Description’ field in the UI Policy form to explain the purpose, conditions, and expected behavior, especially for complex scenarios.
• Leverage Client Scripts Sparingly: While UI Policies are declarative and preferred for simple logic, use Client Scripts when you need more complex logic, server-side interactions, or finer control over the user experience.

Conclusion: Crafting Smarter Forms

The “On Load” checkbox in ServiceNow UI Policies is a cornerstone of creating dynamic, user-friendly forms. By strategically applying these policies, we can significantly enhance the user experience, improve data accuracy, and streamline business processes. Whether you’re hiding unnecessary fields, making critical ones mandatory, or displaying context-specific information, “On Load” UI Policies empower you to sculpt the initial interaction users have with your ServiceNow instance.

Mastering these practical examples and understanding the underlying principles will not only make your ServiceNow implementation more efficient but also position you as a valuable asset in any IT team, and undoubtedly, a standout candidate in your next ServiceNow interview.