GlideModal vs. UI Pages: A Deep Dive for ServiceNow Developers

GlideModal vs. UI Pages: Demystifying ServiceNow’s Dynamic Dialogs

As ServiceNow developers, we’re constantly looking for the most efficient and user-friendly ways to present information and gather input from our users. Two powerful tools in our arsenal for achieving this are GlideModal and UI Pages. While both can create interactive dialogs, understanding their distinct characteristics, use cases, and underlying mechanisms is crucial for building robust and maintainable ServiceNow solutions.

Often, newcomers to ServiceNow might conflate these two. After all, both can pop up a window! However, the reality is far more nuanced. GlideModal is a client-side scripting API, a lightweight way to create simple, task-specific modal windows that overlay your current form or list. UI Pages, on the other hand, are more akin to full-fledged web pages rendered within the ServiceNow platform, offering greater flexibility and complexity.

In this comprehensive article, we’ll break down the core differences between GlideModal and UI Pages, providing practical explanations, real-world examples, and insights that will not only improve your development but also prepare you for those inevitable technical interviews.

The Essence of GlideModal: Quick, Contextual Interactions

Think of GlideModal as your go-to for quick, on-the-fly interactions that are tightly coupled to the user’s current context. It’s designed to be straightforward, allowing you to display messages, confirm actions, or gather minimal input without taking the user away from their current task. The primary advantage of GlideModal lies in its simplicity and the fact that it operates within the existing ServiceNow UI framework.

How GlideModal Works

GlideModal is a client-side scripting API. This means its logic executes in the user’s browser. You’ll typically invoke GlideModal functions within client scripts (like `onLoad`, `onChange`, or `onSubmit` scripts) or within UI Actions. When you call a GlideModal function, it renders a modal window that appears on top of the current ServiceNow page.

There are several types of GlideModal, each suited for different purposes:

`GlideDialogWindow`: The most common and versatile. It allows you to display custom HTML content, capture user input via forms, and control dialog behavior.
`GlideModal` (deprecated but still seen): A precursor to `GlideDialogWindow`. While still functional, it’s recommended to use `GlideDialogWindow` for new development.
`GlideAjax` (indirectly related): While not a dialog itself, `GlideAjax` is often used in conjunction with GlideModal to fetch server-side data to populate or process information within the modal.

Key Characteristics of GlideModal

Client-Side Execution: Primarily runs in the browser.
Overlay Interface: Appears as a modal window on top of the current page.
Contextual: Tightly linked to the record or list the user is interacting with.
Simple UI: Typically uses basic HTML, CSS, and JavaScript for its content.
Limited Complexity: Best for simple tasks and information display.
Performance Focused: Generally lightweight and quick to load.

When to Use GlideModal: Practical Scenarios

Let’s illustrate with some everyday ServiceNow development scenarios where GlideModal shines:

Confirmation Prompts: Before a user can submit a critical record (e.g., an Incident with a high severity), you might want a confirmation dialog.


// Example in a UI Action's 'Client' script
function confirmSubmit() {
    var dialog = new GlideDialogWindow('my_confirmation_dialog'); // Assumes you have a UI Page named 'my_confirmation_dialog'
    dialog.setTitle('Confirm Submission');
    dialog.setPreference('message', 'Are you sure you want to submit this high priority incident?');
    dialog.render();
}

Here, `my_confirmation_dialog` would be a simple UI Page with minimal HTML to display the message and potentially “Yes” and “No” buttons. The dialog’s response would then be handled by JavaScript.

Displaying Quick Information: Showing a user a brief summary of related information without navigating away from the current form.


// Example in an onLoad Client Script
function displayRelatedInfo() {
    var dialog = new GlideDialogWindow('related_record_viewer'); // A UI Page to display related record details
    dialog.setTitle('Related Incident Details');
    dialog.setPreference('sys_id', g_form.getUniqueValue()); // Pass current record's sys_id
    dialog.render();
}

The `related_record_viewer` UI Page would then use the passed `sys_id` to query for and display relevant data.

Gathering Simple Input: Collecting a short piece of text or a selection from a limited set of options.


// Example in a UI Action's 'Client' script
function requestAdditionalInfo() {
    var dialog = new GlideDialogWindow('request_info_dialog');
    dialog.setTitle('Request Additional Information');
    dialog.setPreference('question', 'Please provide a brief reason for this rejection:');
    dialog.render();
}

The `request_info_dialog` UI Page would contain an input field and submit buttons.

The GlideModal API in Action

Here’s a more in-depth look at using `GlideDialogWindow`:

Basic Structure:


var dialog = new GlideDialogWindow('your_ui_page_name'); // The name of the UI Page to render
dialog.setTitle('Your Dialog Title');
dialog.setPreference('preference_name', 'preference_value'); // Key-value pairs passed to the UI Page
dialog.render();

Receiving Preferences in the UI Page:

Within your UI Page’s HTML, you can access these preferences using the `prefs` object:


<g:evaluate var="jvar_message" expression="RP.getWindowProperties().get('message')" />
<p>${jvar_message}</p>

Handling Dialog Submission (Client-Side):

You’ll often have buttons in your UI Page that trigger client-side JavaScript to close the dialog and perform actions. This is typically done via functions defined in the UI Page’s Client Script or within the UI Page’s HTML itself.


// In the UI Page's Client Script
function submitDialog() {
    var userInput = gel('my_input_field').value; // Get value from an input field
    GlideDialogWindow.get().destroy(); // Close the dialog
    // Perform actions with userInput, e.g., GlideAjax call to server
}

The Power of UI Pages: Flexible, Standalone Web Applications

UI Pages are where you go when you need more control, more complexity, and a more distinct user experience. They are essentially self-contained web pages hosted within the ServiceNow instance. This means you can leverage the full power of HTML, CSS, and JavaScript to build intricate interfaces, integrate with multiple server-side scripts, and create sophisticated workflows.

How UI Pages Work

A UI Page is a ServiceNow record that defines a web page. It consists of:

HTML: The structure and content of the page.
Client Script: JavaScript that runs in the user’s browser.
Server Script: Server-side JavaScript that runs when the page is loaded or when specific actions are triggered.
CSS: Styling for the page.

UI Pages can be invoked in several ways:

Directly via URL: `nav_to.do?uri=sys_ui_page.do?sys_id=YOUR_UI_PAGE_SYS_ID` or `YOUR_UI_PAGE_NAME.do`.
From UI Actions: Using `openUrlInWindow()` or by making them the target of a `GlideModal` dialog.
From Client Scripts: To be rendered within a `GlideModal` window.
As Content Blocks: In Service Portal.

Key Characteristics of UI Pages

Server-Side and Client-Side Logic: Can execute code on both the server and the client.
Standalone Pages: Can be designed to function independently.
Rich UI Capabilities: Supports complex HTML, CSS frameworks, and JavaScript libraries.
Extensive Data Interaction: Can perform complex queries and manipulations on ServiceNow data.
Reusability: Can be designed as reusable components.
Service Portal Integration: Foundation for many Service Portal widgets.

When to Use UI Pages: Advanced Scenarios

UI Pages are the powerhouse for more demanding requirements:

Complex Forms and Wizards: When you need a multi-step process to gather extensive user input.


<!-- Example snippet from a UI Page for a multi-step wizard -->
<div id="step1">
    <h3>Step 1: Select Options</h3>
    <select id="option_select">
        <option value="A">Option A</option>
        <option value="B">Option B</option>
    </select>
    <button onclick="nextStep('step2')">Next</button>
</div>
<div id="step2" style="display:none;">
    <h3>Step 2: Enter Details</h3>
    <input type="text" id="detail_input" />
    <button onclick="submitWizard()">Submit</button>
</div>

The client script within this UI Page would handle showing/hiding steps and collecting all data for final submission.

Custom Dashboards or Reporting Interfaces: Building bespoke dashboards that pull data from various sources.


<!-- Example snippet for displaying a chart -->
<div id="incident_chart"></div>

<script>
// Client-side script to fetch data and render chart
var ga = new GlideAjax('MyChartDataScriptInclude');
ga.addParam('sysparm_name', 'getIncidentData');
ga.getXMLAnswer(function(answer) {
    // Process answer and render chart using a JavaScript charting library
});
</script>

The `MyChartDataScriptInclude` would be a Script Include performing server-side queries.

Integration with External Tools or Services: Creating interfaces that interact with APIs outside of ServiceNow.
Service Portal Widgets: While Service Portal has its own widget framework, UI Pages can serve as the backend logic or complex frontend components for these widgets.
Advanced User Interfaces on Standard Forms: If a standard form widget isn’t sufficient, a UI Page can be embedded or called to provide a richer user experience for a specific task.

UI Page Structure and Development

When developing a UI Page, you’ll typically be working across different tabs in the UI Page record:

HTML: Where you define the page layout and content. You can use ServiceNow-specific tags (`g:`) for server-side processing.
Client Script: For browser-side interactivity, form validation, and AJAX calls.
UI Macros: Reusable snippets of HTML and Jelly that can be embedded in UI Pages.
Processing Script: Server-side script executed when the page is loaded. Useful for fetching initial data.
Style Sheets: To define the page’s visual appearance.

Example of Server-Side Processing in a UI Page:


<!-- UI Page HTML -->
<g:evaluate var="jvar_incident_number" expression="RP.getWindowProperties().get('incident_number')" />

<h2>Details for Incident: ${jvar_incident_number}</h2>

<!-- Server-side script to fetch and display incident details -->
<g:if test="${jvar_incident_number != ''}">
    <g:evaluate object="incident_gr" var="jvar_incident_gr">
        var gr = new GlideRecord('incident');
        gr.get('number', '${jvar_incident_number}');
        gr;
    </g:evaluate>
    <p>Short Description: ${jvar_incident_gr.short_description}</p>
    <p>State: ${jvar_incident_gr.state.getDisplayValue()}</p>
</g:if>

In this example, `${jvar_incident_number}` is passed from the `GlideModal` (or directly) and then used server-side within the UI Page to query the `incident` table.

GlideModal vs. UI Pages: The Key Differences at a Glance

To solidify your understanding, let’s compare them head-to-head:

Feature	GlideModal (using GlideDialogWindow)	UI Page
Execution Environment	Primarily Client-Side (browser)	Both Client-Side and Server-Side
Purpose	Quick, contextual, simple interactions, confirmations, minimal input.	Complex forms, wizards, standalone pages, custom UIs, reporting.
Complexity	Low to Moderate	Moderate to High
UI Flexibility	Limited by HTML/CSS within the modal. Often relies on a simple UI Page for content.	Highly flexible; full control over HTML, CSS, and JS.
Data Interaction	Usually involves `GlideAjax` to fetch/process data server-side.	Can directly query tables server-side within the UI Page or via Script Includes.
Development Effort	Generally quicker for simple tasks.	Can be more involved due to the scope of the page.
Performance	Typically lightweight and fast.	Can vary based on complexity and server-side processing.
Reusability	The `GlideDialogWindow` calls are reusable, but the UI Page content might be specific.	UI Pages are inherently reusable components.

Troubleshooting Common Issues

Even with these powerful tools, you might encounter bumps in the road. Here are some common troubleshooting scenarios:

GlideModal Issues

Dialog Not Appearing:
- Check Client Script Execution: Is the client script triggering correctly? Use `g_form.debug()` or browser developer tools to inspect.
- UI Page Name Typo: Double-check the UI Page name passed to `GlideDialogWindow()`.
- `g_form` Availability: Ensure `g_form` is available in the context (e.g., not in a `UI Macro` that doesn’t have it).
- UI Action Conditions: If invoked from a UI Action, ensure the conditions for the UI Action are met.
Preferences Not Being Passed or Received:
- Correct `setPreference` and `RP.getWindowProperties().get()`: Ensure the preference names match exactly between the client script and the UI Page.
- Client-Side vs. Server-Side: Remember `setPreference` is called client-side, and `RP.getWindowProperties().get()` is used within the UI Page’s server-side processing or HTML.
Dialog Closes Immediately:
- Uncaught JavaScript Errors: Check the browser’s developer console for JavaScript errors in your UI Page’s client script or HTML.
- Incorrect `GlideDialogWindow.get().destroy()`: Ensure `destroy()` is only called after your intended logic has executed.

UI Page Issues

Page Not Loading Correctly / Blank Page:
- Server Script Errors: Check the System Logs (`syslog`) for errors originating from your UI Page’s server script or any Script Includes it calls.
- HTML/Jelly Syntax Errors: Malformed HTML or Jelly can prevent rendering.
- Permissions: Ensure the user has roles to access the table and data the UI Page is trying to display.
Client Script Not Working:
- JavaScript Errors: Use browser developer tools (console) to find errors.
- Incorrect DOM Manipulation: Ensure elements you’re trying to interact with exist and have the correct IDs/classes.
- `g_form` Not Available: If the UI Page is not loaded on a form, `g_form` might not be available.
`GlideAjax` Calls Failing from UI Page:
- Script Include Name/Function Typo: Verify the `sysparm_name` and the function name in your `GlideAjax` call.
- Script Include Logic Errors: Check the `syslog` for errors in the Script Include.
- ACLs (Access Control Lists): Ensure the user has necessary read/write ACLs on the tables the Script Include is accessing.
Styling Issues:
- CSS Specificity: Ensure your CSS rules are specific enough to override default ServiceNow styles if necessary.
- Incorrect CSS Selectors: Verify that your CSS selectors correctly target the HTML elements.

Interview Relevance: Mastering the Concepts

When you’re in a ServiceNow technical interview, demonstrating a clear understanding of GlideModal and UI Pages can set you apart. Here are some common questions and how to approach them:

Common Interview Questions:

“When would you use a GlideModal versus a UI Page?”
Answer Strategy: Start by defining each. GlideModal for quick, in-context actions, confirmations, and simple inputs. UI Pages for complex forms, wizards, standalone applications, and rich user interfaces. Provide a concise example for each. Mention the client-side nature of GlideModal vs. the server/client capabilities of UI Pages.
“Can you explain the difference between `GlideDialogWindow` and the older `GlideModal`?”
Answer Strategy: Explain that `GlideDialogWindow` is the modern, recommended API for creating modal dialogs that often leverage UI Pages for their content. Mention that `GlideModal` is a deprecated API and to favor `GlideDialogWindow` for new development.
“How do you pass data from a client script to a UI Page when using GlideModal?”
Answer Strategy: Describe using `dialog.setPreference(‘key’, ‘value’)` in the client script and then accessing `RP.getWindowProperties().get(‘key’)` within the UI Page’s HTML or server script.
“What are the main components of a UI Page?”
Answer Strategy: List HTML, Client Script, Server Script, and potentially UI Macros and CSS. Briefly explain the role of each.
“Describe a scenario where you would need to use a UI Page instead of a simple form or UI Action.”
Answer Strategy: Focus on complexity. For example, a multi-step approval process with dynamic fields, or a custom reporting interface that needs to aggregate data from disparate sources, or a workflow that requires specific user interaction not achievable with standard form elements.
“How do you handle server-side logic within a UI Page?”
Answer Strategy: Explain the ‘Processing Script’ tab and the use of Jelly tags like `` for server-side execution and variable retrieval within the HTML. Also, mention using `GlideAjax` from the UI Page’s client script to call Script Includes.

Pro Tip for Interviews: Always be ready to back up your answers with specific examples from your experience. If you haven’t built something complex with a UI Page, think about hypothetical scenarios and how you would approach them.

Conclusion: Choosing the Right Tool for the Job

GlideModal and UI Pages are both indispensable tools in the ServiceNow developer’s toolkit, each serving a distinct purpose. GlideModal excels at delivering swift, context-aware interactions, making it perfect for confirmations and simple data collection directly tied to a user’s current workflow. On the flip side, UI Pages offer unparalleled flexibility, enabling the creation of sophisticated, standalone web applications within the ServiceNow platform. They are the backbone for complex wizards, custom reporting, and rich user interfaces.

By understanding their core differences, use cases, and development paradigms, you can confidently choose the most appropriate solution for your specific requirements. Mastering these concepts not only leads to more efficient and user-friendly ServiceNow implementations but also demonstrates a deep technical proficiency that will be highly valued in your career.

Remember, the key is to assess the complexity of the user interaction needed. For a quick question or confirmation, GlideModal is your friend. For building a mini-application within ServiceNow, turn to UI Pages.