Mastering UI Pages in ServiceNow: A Comprehensive Guide for Developers

By /






Building User Interface Pages in ServiceNow: A Deep Dive


Building User Interface Pages in ServiceNow: A Deep Dive into Forms, Policies, and More

In the world of ServiceNow, a robust and intuitive user interface (UI) is paramount for efficient service management. Whether you’re an administrator, developer, or even a power user, understanding how to build and customize UI pages is key to tailoring the platform to your organization’s specific needs. This article will take you on a comprehensive journey, exploring the fundamental building blocks of ServiceNow UIs, from creating records to implementing complex logic, all while keeping best practices and real-world scenarios in mind.

Foundational Concepts: Users, Groups, and Permissions

Before we dive into UI elements, it’s crucial to establish a solid understanding of how users and their access are managed in ServiceNow. This forms the bedrock upon which all UI interactions are built.

User and Group Management

ServiceNow meticulously tracks its users and their group affiliations. The primary table for user information is sys_user. Groups, on the other hand, are managed within the sys_user_group table. These tables are the central repositories for who is using the system and how they are organized.

Role-Based Access Control (RBAC) and Best Practices

Permissions in ServiceNow are primarily managed through roles. You can assign roles directly to individual users or, more effectively, to groups. The best practice here is to leverage group memberships for role assignments. Why? Because when an employee leaves the organization, simply removing them from the relevant groups automatically revokes their associated roles and permissions. This significantly simplifies user lifecycle management and reduces the risk of orphaned access.

Programmatically, you can manage user and group roles. A record is created in the sys_user_has_role table when a role is assigned to a user, and in the sys_group_has_role table for group role assignments. Scripts using GlideRecord can be employed to dynamically add or remove these associations.

Example: Assigning a Role to a User via Script

If you need to grant a user the ‘itil’ role, you’d typically find the sys_id of both the user and the role and then create a record in sys_user_has_role:


    var userRole = new GlideRecord('sys_user_has_role');
    userRole.setValue('user', 'YOUR_USER_SYS_ID'); // e.g., '62826bf03710200044e0bfc8bcbe5df1'
    userRole.setValue('role', 'YOUR_ROLE_SYS_ID'); // e.g., '2831a114c611228501d4ea6c309d626d' (for itil role, example sys_id)
    userRole.insert();

Example: Assigning a Role to a Group via Script

Similarly, for groups:


    var grpRole = new GlideRecord('sys_group_has_role');
    grpRole.setValue('group', 'YOUR_GROUP_SYS_ID'); // e.g., '477a05d153013010b846ddeeff7b1225'
    grpRole.setValue('role', 'YOUR_ROLE_SYS_ID'); // e.g., '2831a114c611228501d4ea6c309d626d'
    grpRole.insert();

User Delegation: Working on Behalf of Others

User delegation is a powerful feature that allows one user to perform actions on behalf of another. This is incredibly useful for scenarios like vacations or extended leaves. The delegated user gains the necessary permissions to access resources and complete tasks normally handled by the original user. This is configured within the original user’s record under the ‘Delegates’ related list.

Core UI Components: Forms and Their Behavior

Forms are the most common way users interact with records in ServiceNow. They present data in a structured, user-friendly manner and allow for data input and modification.

Creating and Manipulating Records

You can create records in ServiceNow tables through various means:

  • Forms: The standard graphical interface.
  • Record Producers: Special forms designed to create records from the Service Catalog.
  • Email: Inbound email actions can create records.
  • GlideRecord: Server-side scripting for programmatic record creation.
  • Excel Sheets: Data import using transform maps.
  • External Systems: Via integrations (e.g., REST APIs).

Example: Creating an Incident Record via Script


    var gr = new GlideRecord('incident');
    gr.initialize();
    gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys ID of the caller
    gr.category = 'inquiry';
    gr.subcategory = 'antivirus';
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the Configuration Item
    gr.short_description = 'Test record created via script';
    gr.description = 'This is a detailed description for the test incident.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
    gr.insert();

Similar scripts can be used for creating problem and change_request records, substituting the table name and relevant fields.

Field Types: The Building Blocks of Forms

ServiceNow offers a rich array of field types to accommodate diverse data needs. Some common ones include:

  • String: For text input.
  • Reference: To link to records in other tables.
  • List: A multi-select reference field.
  • Choice: For predefined dropdown options.
  • Email: For email addresses, with validation.
  • Date/Time: For date and time selection.
  • Date: For date selection only.
  • Boolean: True/False values (often represented as checkboxes).
  • Integer: For whole numbers.
  • Journal: For comment-style entries, often with history.
  • Attachment: To upload files.

Controlling Field Behavior: Mandatory, Read-Only, and Display

Ensuring data integrity and guiding user input is crucial. You can make fields mandatory, read-only, or control their display status using several methods:

  • Dictionary Properties: Directly on the field’s dictionary entry.
  • Dictionary Overrides: To modify a parent table’s field behavior in a child table.
  • UI Policies: Client-side scripting for dynamic form behavior based on conditions.
  • Data Policies: Both client-side and server-side for enforcing data consistency.
  • Client Scripts: Using g_form.setMandatory('field_name', true/false); on the client-side.

Important Note: A table can only have one field designated as ‘display’. This field’s value is what’s shown in reference fields that link to this table, and having more than one would lead to confusion.

Setting Default Values

To pre-populate fields when a form loads, you can set default values in the field’s dictionary entry. This saves users time and ensures consistency.

Attributes: Customizing Field Behavior

Attributes are powerful modifiers that can be applied to fields (or even tables) to alter their behavior. Some common examples include:

  • no_email: Disables email notifications for changes to this field.
  • no_attachment: Prevents attachments for this record.
  • tree_picker: Enables a hierarchical display for reference fields.

You can disable attachments on a form by adding the no_attachment attribute to the collection field (which represents the table itself) in its dictionary entry.

Advanced UI Control: Policies and Qualifiers

Beyond basic field settings, ServiceNow offers sophisticated tools to dynamically control UI behavior and data filtering.

UI Policies vs. Data Policies

UI Policies operate on the client-side and are excellent for real-time form interactions – making fields mandatory, read-only, visible, or hidden as users interact with the form. They can also control related lists.

Data Policies, on the other hand, enforce data consistency at both the client and server levels, ensuring rules are applied regardless of how data is entered (e.g., form, import, API). They can also make fields mandatory or read-only.

A UI Policy can be converted to a Data Policy, but this isn’t always straightforward. Cases where conversion might be problematic include:

  • Controlling data visibility (e.g., show/hide fields).
  • Controlling views.
  • Controlling related lists.
  • Complex script logic tied to UI-specific actions.

Understanding the ‘Global’ and ‘Reverse if False’ Checkboxes in UI Policies

The ‘Global’ checkbox ensures a UI Policy applies across all views. If unchecked, you’ll specify which view(s) it should apply to.

‘Reverse if False’ is crucial for dynamic behavior. If checked, when the UI Policy’s conditions become false, the actions applied will be reversed (e.g., a field made mandatory will become optional again).

The ‘On Load’ checkbox determines if the UI Policy runs as soon as the form loads. If unchecked, it only triggers when specific field changes meet its conditions.

The ‘Inherit’ checkbox allows UI Policies to be applied to child tables that extend the table the policy is defined on.

Reference Qualifiers: Refining Reference Field Data

Reference qualifiers are essential for limiting the records displayed in reference and list fields. They act as filters.

  • Simple Reference Qualifier: Uses basic, static query conditions (e.g., active=true).
  • Dynamic Reference Qualifier: Leverages predefined dynamic filter options, allowing for context-aware filtering based on other form fields or user attributes.
  • Advanced Reference Qualifier (JavaScript): Offers the most flexibility, allowing custom JavaScript code to define complex filtering logic. This is where you can build intricate conditions based on multiple fields, user roles, or system properties.

Example: Advanced Reference Qualifier


    javascript: 'assignment_group=' + current.assignment_group + '^priority<3';

This qualifier would filter a reference field to show only records associated with the same assignment group as the current record and having a priority less than 3.

Dependent Values: Cascading Dropdowns

Dependent values enable cascading dropdowns. When a user selects a value in a “parent” field (e.g., Category), the choices in a “dependent” field (e.g., Subcategory) dynamically update to show only relevant options. This is configured by setting the ‘Dependent Field’ attribute on the dependent field’s dictionary entry.

Calculated Values: Deriving Field Data

If you need a field’s value to be automatically calculated based on other fields using server-side logic, you can utilize the ‘Calculated value’ option in the field’s dictionary entry. This often involves using the current object within a script.

Understanding Table Relationships and Structure

ServiceNow’s data model is built on tables, and understanding their relationships is key to effective development.

Out-of-the-Box (OOTB) Tables vs. Custom Tables

OOTB tables are those provided by ServiceNow and do not start with x_ or u_. Custom tables, created by administrators or developers, typically begin with these prefixes.

Base Tables: The Foundation of the Data Model

Base tables, like task and cmdb_ci, are foundational tables that don’t extend other tables but are extended by many other tables. This inheritance allows for shared fields and behaviors.

Task Tables: Workflows and Assignments

Tables like incident, problem, and change_request all extend the task table. This means they inherit common fields and functionalities related to work tasks.

Table Extensions and the ‘Class’ Field

When you extend a table, the child table inherits fields from the parent. This means sys fields are not duplicated. A special ‘class’ field is added to the parent table to track which specific child table a record belongs to. A table extending multiple other tables will still have only one ‘class’ field.

One-to-One vs. One-to-Many vs. Many-to-Many Relationships

  • One-to-Many: A single record in one table can be related to multiple records in another (e.g., one User can have many Incidents).
  • Many-to-Many: Multiple records in one table can relate to multiple records in another. This often involves a “glue” table (e.g., Incidents and Groups – an Incident can be assigned to many groups, and a Group can work on many Incidents, managed by a sys_user_group_members table or similar).

Temporary vs. Normal Tables

Normal tables store data permanently. Temporary tables, often extending import_set_row, store data for a limited period (typically 7 days) and are designed for staging data before it’s permanently loaded or processed. The retention period for temporary tables can be extended using archive rules.

Remote Tables: Live Data Integration

Remote tables provide access to live data from external systems, rather than storing a copy of the data within ServiceNow. This is useful for real-time lookups without data duplication.

Table Storage: The sys_db_object Table

All table definitions within ServiceNow are stored in the sys_db_object table. This includes information about tables, fields, and their configurations.

Business Rules and Automation

Business Rules are server-side scripts that execute when records are displayed, inserted, updated, or deleted. They are crucial for automating processes and enforcing business logic.

Automating Child Incident Closure

A common requirement is to automatically close child incidents when a parent incident is closed. This can be achieved with an “after” business rule on the incident table:


    // Business Rule: Close Child Incidents
    // When: After
    // Update: true
    // Condition: current.state.changesTo(7); // Assuming 7 is the state for 'Closed'

    if (current.state == 7 && current.parent == '') { // Check if it's a closed incident and not already a child itself
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id);
        grChild.query();
        while (grChild.next()) {
            grChild.state = 7; // Set state to Closed
            grChild.update();
        }
    }

Preventing Incident Closure with Open Tasks

To prevent users from closing an incident (or problem, or change) if associated tasks are still open, you can use a “before” business rule or a client-side UI Policy.

Example: Before Business Rule for Incident Closure Prevention


    // Business Rule: Prevent Incident Closure with Open Tasks
    // When: Before
    // Insert: false
    // Update: true
    // Condition: current.state.changesTo(7); // Assuming 7 is the state for 'Closed'

    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
    grTask.query();
    if (grTask.hasNext()) {
        gs.addErrorMessage('Cannot close the incident because there are open incident tasks.');
        current.setAbortAction(true); // Prevents the update (closure)
    }

Similar logic applies to problems and change requests, referencing their respective task tables.

Problem-Incident Relationships and Automation

When a problem is resolved, associated incidents should often be closed as well. A “before” business rule on the problem table can handle this:


    // Business Rule: Close Associated Incidents on Problem Closure
    // When: Before
    // Update: true
    // Condition: current.state.changesTo(7); // Assuming 7 is the state for 'Closed'

    if (current.state == 7) {
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id);
        grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed'
        grIncident.query();
        while (grIncident.next()) {
            grIncident.state = 7; // Set state to Closed
            grIncident.update();
        }
    }

Incident, Problem, and Change Management: The Workflow Nexus

These three processes are intrinsically linked:

  • Incident: A disruption to normal service operation. The immediate goal is restoration.
  • Problem: The underlying cause of one or more incidents. The goal is root cause analysis and prevention of recurrence.
  • Change Request: A formal proposal for an alteration to an IT service. The goal is to manage risk and minimize disruption.

A recurring incident often leads to the creation of a problem record. If the resolution to a problem requires a modification to the IT environment, a change request is initiated.

ACLs (Access Control Lists): Securing Your Data

Access Control Lists (ACLs) are the gatekeepers of your ServiceNow instance, defining who can access what data and perform what actions. When you create a new table, ServiceNow typically generates four default ACLs (read, write, create, delete) if the corresponding checkbox is enabled during table creation.

The security_admin role is required to manage ACLs.

User Interface Elements and Navigation

Application Menus and Modules: Organizing Your UI

Application Menus and Modules are used to create navigation entries in the ServiceNow platform navigator. They make forms, lists, and reports easily accessible to end-users, grouping related functionalities.

Process Flow: Visualizing Workflow Stages

Process flows provide a visual representation of a record’s progress through different stages of a workflow, offering clarity on its current status.

Troubleshooting Common UI Issues

UI Policies Not Applying

Checklist:

  • Is the UI Policy active?
  • Does the condition evaluate correctly for the current record?
  • Is the ‘Global’ checkbox set appropriately for your view?
  • If ‘Inherit’ is used, does the child table correctly extend the parent?
  • Are there conflicting UI Policies or Client Scripts?
  • Ensure ‘Run scripts’ is checked if you are using scripts within the UI Policy Action.

Reference Qualifiers Not Filtering Correctly

Checklist:

  • Verify the syntax of your qualifier (simple, dynamic, or advanced).
  • For dynamic qualifiers, ensure the Dynamic Filter Option is correctly configured and active.
  • For advanced qualifiers, double-check JavaScript syntax and ensure it correctly references fields and the current context.
  • Are there any global scripts or other configurations that might be overriding the qualifier?

Data Policies Not Enforcing Rules

Checklist:

  • Is the Data Policy active?
  • Are the conditions for the Data Policy correct?
  • Check the ‘Use as role’ field if you’ve assigned specific roles to the Data Policy.
  • Remember Data Policies work on both client and server; if the issue is only on the client, consider if a UI Policy is more appropriate or if there’s a conflict.

Interview Relevance

Understanding these concepts is vital for ServiceNow interviews. Be prepared to discuss:

  • The difference between UI Policies and Data Policies.
  • How to implement security using ACLs and roles.
  • Best practices for user and group management.
  • The relationship between Incident, Problem, and Change Management.
  • How to use GlideRecord for scripting.
  • Reference Qualifiers and their types.
  • The purpose of attributes and dictionary overrides.
  • Concepts like impersonation (logging in as another user for testing) and user preferences (user-specific settings).
  • The meaning of ‘current’ and ‘gs’ objects in server-side scripting.

Conclusion

Building effective UI pages in ServiceNow is a multi-faceted skill that combines understanding user management, leveraging form configurations, and implementing dynamic logic through policies and scripts. By mastering these concepts, you can transform ServiceNow from a generic platform into a highly tailored and efficient service management solution for your organization.


Scroll to Top