Mastering Real-World Client Script Validation in ServiceNow

Hey there, fellow ServiceNow enthusiasts! As we navigate the ever-evolving landscape of ServiceNow development, understanding how to effectively implement client-side validation is crucial. It’s not just about making things work; it’s about crafting seamless user experiences, ensuring data integrity, and ultimately, delivering robust solutions that delight our clients. In this article, we’ll dive deep into a realistic client script validation scenario, drawing upon common questions and best practices that often come up during client interactions and technical interviews.

We’ll break down the complexities, explore practical examples, and highlight why mastering these concepts is a game-changer for any ServiceNow professional. So, grab your favorite beverage, settle in, and let’s get scripting!

Understanding the Foundation: Your ServiceNow Journey

Before we get into the nitty-gritty of validation, let’s set the stage. Understanding the version you’re working with and your team’s history with the platform provides valuable context.

Current ServiceNow Version

As of this writing, many organizations are operating on or migrating towards the latest releases. For instance, if you’re working on the Washington DC release (the latest one), you benefit from the most recent features and performance enhancements.

Evolution of Your ServiceNow Experience

It’s always interesting to see how far we’ve come. Many of us started our ServiceNow journey with earlier versions like Rome, San Diego, Tokyo, Utah, or Vancouver, and have progressively moved up to the current release. This progression signifies a deep understanding of the platform’s evolution and a commitment to staying current.

Core Concepts: Users, Groups, and Permissions

At the heart of any ServiceNow implementation are users, groups, and the permissions that govern their access. Understanding how these interact is fundamental to building secure and functional applications.

Managing Permissions: Users and Groups

Absolutely! We can, and often should, add permissions to users and groups. The best practice here is to leverage groups for permission management. Why? Imagine an employee leaves the organization. If roles are directly assigned to the user, you’d have to manually remove each role. However, if permissions are granted via group membership, simply removing the user from their respective groups automatically revokes all associated roles. This is a lifesaver for administration and ensures timely access revocation.

Key Tables for User and Group Management

• User Table Name: sys_user
• Group Member Table Name: sys_user_group (This table links users to groups, often referred to as the ‘members’ table in context.)

Scripting User and Group Operations

Let’s get hands-on with scripting:

Creating a User Account via Script:

This is a common requirement for automated onboarding or integration scenarios.

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();
    

Creating a Group via Script:

Essential for setting up new teams or functional groups.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group'; // A descriptive name
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the manager
newGr.email = 'testing@tcs.com'; // Group email for notifications
newGr.description = 'This is a test group for demonstration purposes.';
newGr.insert();
    

Adding Permissions (Roles) via Script:

This is where we connect users/groups to specific roles. ServiceNow manages this through intermediate tables.

• To a User: A record is created in the sys_user_has_role table.
• To a Group: A record is created in the sys_group_has_role table.

// Adding a role to a user
var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys ID of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
userRole.insert();

// Adding a role to a group
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
grpRole.insert();
    

Adding and Removing Group Members via Script:

Managing group memberships dynamically is a common requirement.

• Adding a Group Member: The sys_user_grmember table links users to groups.

var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys ID of the group
grMem.insert();
        

• Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys ID of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
        

User Delegation

User delegation is a powerful feature that allows one user to act on behalf of another, typically when the original user is unavailable (e.g., on vacation). The delegated user gains the necessary permissions to perform tasks, access resources, and even handle approvals. This ensures business continuity. Configuration involves accessing the original user’s record, scrolling to the ‘Delegates’ related list, and specifying the delegate, dates, and permissions (assignments, notifications, approvals).

Web Services Users

A ‘web services user’ is an account specifically created to allow third-party applications to connect to ServiceNow securely. Crucially, these users cannot log in to the ServiceNow instance as a regular user. Their purpose is solely for programmatic integration.

Client-Side Scripting: The Art of Validation

Client scripts run in the user’s browser and are your primary tool for real-time validation, providing immediate feedback and enhancing the user experience. Let’s explore some key aspects.

Accessing the Current User’s Information

Knowing who the current user is can be vital for conditional logic in client scripts.

• Client-Side: g_user.userID;
• Server-Side: gs.getUserID();

Checking Group Membership (Client-Side)

You might want to show or hide fields based on whether a user belongs to a specific group.

// In a client script (e.g., onLoad or onChange)
if (g_user.isMemberOf('Your Group Name')) { // Or use Sys ID for better performance
    // Perform actions for members of this group
    alert('You are a member of the specified group!');
} else {
    // Actions for users not in the group
    alert('You are not a member of the specified group.');
}
    

Server-Side Scripting and Business Rules

While client scripts provide immediate feedback, server-side scripts, particularly Business Rules, are essential for enforcing data integrity at the database level.

Access Control: The Security Guardian

To work with Access Control Lists (ACLs), you need the security_admin role. ACLs are fundamental for defining who can read, write, create, or delete records in your instance.

Impersonation: A Testing Essential

Impersonation is a powerful tool that allows you to log in as another user for testing purposes. This is invaluable for verifying that ACLs, client scripts, and business rules behave as expected for different user roles and permissions.

User Preferences

User preferences are personal settings that a user can change. These changes only affect the individual user and do not have a global impact. Think of it like customizing your personal dashboard or notification settings.

Incident, Problem, and Change Management Flows

These three modules form the backbone of IT Service Management (ITSM) in ServiceNow. Understanding their relationships and scripting interactions is key.

Defining Incidents and Problems

• Incident: A sudden interruption to a service or a reduction in the quality of a service. The goal is to restore service as quickly as possible.
• Problem: When the same incident or a similar issue occurs repeatedly, it’s often categorized as a problem. A problem record aims to identify the root cause of one or more incidents and prevent their recurrence.

The Incident, Problem, Change Management Relationship

The relationship is hierarchical and logical:

1. A user experiences an issue and creates an Incident.
2. If the same issue arises repeatedly for one or multiple users, a Problem record is created to investigate the root cause. Multiple incidents can be linked to a single problem (child incidents to a parent problem).
3. Once the root cause is identified (via the Problem Management process) or if a resolution requires system modification, a Change Request is initiated to implement the necessary changes to the underlying systems or applications.

This flow ensures that recurring issues are addressed systematically, and changes are managed under a controlled process to minimize disruption.

Scripting ITSM Records

Let’s look at how to create these records programmatically:

Creating an Incident Record using Script:

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

Creating a Problem Record using Script:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test problem record created via script.';
gr.description = 'This is a detailed description of the problem for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
    

Creating a Change Request using Script:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry'; // e.g., 'Standard', 'Normal', 'Emergency'
gr.subcategory = 'antivirus'; // e.g., 'Software Update', 'Hardware Replacement'
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test change request created via script.';
gr.description = 'This is a detailed description of the change request for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
    

Automating Workflows with Business Rules

Business Rules are the workhorses for server-side automation and validation.

Scenario: Closing Parent Incident Closes Child Incidents

This is a classic requirement to ensure comprehensive closure.

Type: After Business Rule

When: After

Update: True

Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’)

if (current.state == 7 && current.parent == '') { // Check if it's a top-level incident being closed
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();

    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident
    }
}
    

Scenario: Prevent Incident Closure if Tasks are Open

This ensures that all associated work is completed before an incident is marked as resolved.

Type: Before Business Rule

When: Before

Update: True

Condition: current.state.changesTo(7)

// Check for open incident tasks
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 tasks.');
    current.setAbortAction(true); // Prevent the update
}
    

This logic can be replicated for Problem and Change Request by querying their respective task tables (e.g., problem_task, change_task).

Scenario: Closing Problem Closes Associated Incidents

This helps in clearing out related incidents once the root cause is addressed.

Type: After Business Rule

When: After

Update: True

Condition: current.state.changesTo(7)

if (current.state == 7) { // If the problem is being closed
    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link via problem_id field on incident
    grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed'
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
    }
}
    

ServiceNow Tables and Their Characteristics

Understanding ServiceNow’s data model is fundamental. Let’s touch upon key concepts like table types, fields, and their behaviors.

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

• Out-of-the-Box Tables: These are tables provided by ServiceNow by default. They typically do not start with x_ or u_. Examples include incident, problem, change_request, sys_user.
• Custom Tables: Tables created by administrators or developers. They usually start with x_ (for scoped applications) or u_ (for global applications).

Base Tables

These are foundational tables that other tables extend. They provide common fields and functionality. Examples include task (extended by incident, problem, change request) and cmdb_ci (the base for Configuration Items).

Task Table Extensions

Examples of tables that extend the task table include: incident, problem, change_request, sc_request, sc_req_item, problem_task, change_task, incident_task. This inheritance means they all share common fields like short description, description, state, assignment group, caller, etc.

Access Controls on New Tables

By default, when you create a new table and the “Create 4 Access Control entries” checkbox is selected, ServiceNow will automatically generate four ACLs (read, write, create, delete) for that table. Unchecking this box skips this automatic creation.

Numbering Fields (Auto-Number)

To create fields like incident number, you configure this under the ‘Control’ tab of the dictionary entry for the field. You specify a prefix (e.g., INC) and the number of digits. The ‘Auto number’ field must be checked.

Table Extension and the ‘Class’ Field

When you extend a table, the child table inherits fields from the parent. Crucially, ServiceNow adds a field named class to the parent table. This field stores the sys_id of the actual child table record. If a table extends multiple tables (which is rare and generally discouraged due to complexity), it will still have only one class field in the ultimate parent, pointing to the most specific child table.

Common Field Types

Here are 10 common field types you’ll encounter:

1. Reference
2. String
3. List (for multi-select references)
4. Choice
5. Email
6. Date/Time
7. Date
8. Boolean (True/False)
9. Integer
10. Journal (for work notes and comments)
11. Attachment (though not a typical field *type* for data, it’s a feature)

Temporary vs. Normal Tables

• Temporary Tables: Designed for short-term data storage, often used for imports. Data typically lasts for 7 days and they extend the import_set_row table.
• Normal Tables: Store data permanently until explicitly deleted.

Increasing Retention Period for Temp Tables: This can be achieved using archive rules, though it’s less common for typical temp table use cases.

Remote vs. Normal Tables

• Remote Tables: These tables display live data from an external source (e.g., through REST or SOAP integrations). You’re essentially querying data in real-time.
• Normal Tables: Contain data that is stored directly within the ServiceNow instance.

Table Relationships: One-to-One and One-to-Many

ServiceNow primarily deals with One-to-Many and Many-to-Many relationships.

• One-to-Many: A single record in one table can relate to multiple records in another table. Example: One user can have many incidents.
• Many-to-Many: Multiple records in one table can relate to multiple records in another table. Example: An incident can be assigned to multiple groups, and a group can have multiple incidents assigned to it (often implemented using a reference list field or an intermediary table).

Record Creation and Field Manipulation

Understanding how to create and modify records is fundamental. Let’s explore the ways and then delve into field properties.

Ways to Create a Record in ServiceNow

1. Form: The standard user interface for manual record creation.
2. Record Producer: A type of catalog item that creates a record in a table based on user input.
3. Email: Inbound email actions can create records.
4. GlideRecord: Server-side scripting for programmatic creation.
5. Excel Sheet (Import Set): Using data import features.
6. External System: Via REST APIs or other integration methods.

Making Fields Mandatory or Read-Only

You have several powerful tools at your disposal:

• Dictionary Properties: Set default mandatory/read-only status in the field’s dictionary entry.
• Dictionary Overrides: Override properties of a field from a parent table for a child table.
• UI Policies: Client-side, condition-based visibility, mandatory, and read-only control.
• Data Policies: Server-side (and optionally client-side) enforcement of mandatory and read-only fields.
• Client Scripts (g_form methods): g_form.setMandatory('field_name', true/false); and g_form.setReadOnly('field_name', true/false); for immediate client-side control.

Display Fields

A table can have only one display field. This field’s value is typically shown in related list columns or in the ‘display value’ of reference fields. Having more than one would lead to confusion.

Table Storage

All table definitions (metadata) in ServiceNow are stored in the sys_db_object table.

Setting Default Field Values

You can set default values in the dictionary entry of a field. This populates the field with a pre-defined value when a new record is created on that table, saving users time and ensuring consistency.

Advanced Field and Reference Management

As we delve deeper, understanding how to refine field behavior and filter reference data becomes crucial for building sophisticated applications.

The `current` Object

On the server-side (e.g., in Business Rules, Script Includes), the current object represents the record being processed. You use it to get and set field values.

Setting Field Values with `current`

• current.setValue('field_name', value);: Sets the actual value (e.g., sys_id for a reference field, a string for a string field).
• current.setDisplayValue('field_name', value);: Sets the display value. For reference fields, you provide the human-readable name, not the sys_id. This is useful when you want to set a reference field to a specific named record without knowing its sys_id beforehand.

Reference Qualifiers: Refining Reference Fields

Reference Qualifiers are essential for filtering the records that appear in a reference or list field, making data selection more precise and user-friendly.

Types of Reference Qualifiers:

1. Simple Reference Qualifier

   Description: The most straightforward type, allowing you to define a static query directly in the dictionary entry. It filters records based on fixed conditions.

   Example: To show only active users in a reference field:

   active=true

   Difference from others: It’s static and doesn’t dynamically adjust based on other form fields unless those fields are hardcoded into the qualifier.

2. Dynamic Reference Qualifier

   Description: Leverages “Dynamic Filter Options” defined in System Definition > Dynamic Filter Options. These options can be more context-aware and reusable.

   Example: Displaying only users who are members of the *same assignment group* as the current record’s assignment group. You’d define a Dynamic Filter Option that captures this logic.

   Difference from others: Offers more flexibility than Simple by using pre-defined, context-sensitive filters. It’s less complex to set up than Advanced for certain dynamic scenarios.

3. Advanced Reference Qualifier (JavaScript)

   Description: This is the most powerful type, allowing you to write custom JavaScript code to filter reference records. You can incorporate complex logic, interact with other form fields, and perform intricate calculations.

   Example: Filtering incidents to show only those assigned to the current user’s assignment group AND have a priority less than 3.

   javascript: 'assignment_group=' + g_user.getMyGroups().join(',') + '^prioritySTARTSWITH1,2';

   (Note: The actual JavaScript might be more complex, often involving a Script Include for cleaner code. A simpler example would be `javascript: ‘caller_id=’ + g_user.userID;` to show incidents related to the current user.)

   Difference from others: Offers ultimate flexibility for complex, context-dependent filtering. It requires coding knowledge.

Dependent Values

Dependent values create cascaded dropdowns. When a user selects a value in a “parent” field (e.g., Category), the “dependent” field (e.g., Subcategory) dynamically updates to show only relevant choices. This is configured in the dictionary entry of the dependent field by setting its Dependent Field attribute to the parent field and then defining choices that link specific parent values to dependent choices.

Calculated Values

When you want a field’s value to be automatically computed based on other fields, you use a “Calculated” dictionary property. This allows you to define a formula or script directly in the field’s dictionary entry to derive its value.

Attributes

Attributes are special directives placed in the dictionary entry of a field (or the table’s collection field) to modify its behavior. They are powerful for quick customizations without complex scripting.

Examples of Attributes:

• no_email: Prevents the field from being included in email notifications.
• no_attachment: Disables attachments for the field or table.
• tree_picker: Enables a tree-like structure for selection in reference fields.
• ref_auto_completer=true: Enables auto-completion for reference fields.

Enabling/Disabling Attachments: You’d typically add the no_attachment=true attribute to the *collection field* (the entry representing the table itself) to disable attachments for the entire table.

Dictionary Overrides

Dictionary overrides are used to change the default configuration of a field from a parent table when it’s used in a child table. For instance, you might want the ‘Priority’ field in the Incident table to have a default value of ‘5’ (high) instead of the default ‘4’ (medium) inherited from the Task table. You achieve this by creating a dictionary override for the ‘Priority’ field on the ‘Incident’ table.

User Interface and Navigation Elements

How users interact with ServiceNow is as important as the functionality itself.

Application Menus and Modules

Application Menus are the top-level navigation items in the left-hand navigator (e.g., “Self-Service,” “Incident,” “Problem”). Modules are sub-items within an application menu that link to specific lists, forms, or reports (e.g., “Open Incidents,” “Create New Incident”). They make forms and lists accessible to end-users.

Process Flow

Process flow provides a visual indicator of the current stage or state of a record within a workflow. It helps users understand where they are in a process (e.g., stages in an Incident, Problem, or Change Request lifecycle).

Data Lookup Rules

Data lookup rules allow you to automatically populate field values based on other field values on the form. This is configured in a separate table and provides a dynamic way to set default or calculated values without explicit scripting for every scenario.

Client-Side Scripting: UI Policies and Data Policies

These are powerful tools for controlling form behavior and data integrity.

UI Policies

UI Policies are client-side scripts that make fields mandatory, read-only, visible/invisible, or update their values based on certain conditions. They are generally preferred over client scripts for simple UI manipulations because they are easier to configure declaratively.

• Global Checkbox: When checked, the UI Policy applies to all views. If unchecked, you must specify the view(s) it should apply to.
• Reverse if False: If checked, the actions defined in the UI Policy will be reversed when the condition evaluates to false. For example, if a field is made mandatory when the condition is true, it will become optional again when the condition is false.
• On Load Checkbox: If checked, the UI Policy’s conditions and actions are evaluated as soon as the form loads. If unchecked, actions only trigger when specific field changes meet the condition.
• Inherit Checkbox: When checked, the UI Policy will also apply to child tables that extend the table on which the UI Policy is defined.

Writing Scripts in UI Policies: You can include custom JavaScript in UI Policies by enabling the “Run scripts” checkbox for both the main UI Policy and its associated UI Policy Actions.

Data Policies

Data Policies are similar to UI Policies but operate at the server-side (and can optionally run client-side). They enforce data consistency regardless of how the data is entered (form, import, email, API). They can make fields mandatory or read-only.

UI Policy vs. Data Policy Conversion

You can convert a UI Policy into a Data Policy by opening the UI Policy and clicking the “Convert this UI policy to a Data Policy” button. However, this conversion has limitations.

Conclusion

Navigating the complexities of ServiceNow development, especially client script validation, requires a solid understanding of its architecture, scripting capabilities, and best practices. By internalizing concepts like user and group management, the incident-problem-change lifecycle, data model specifics, and powerful UI/Data policy controls, you’re not just answering interview questions – you’re building better, more reliable ServiceNow solutions.

Keep practicing, keep exploring, and always strive to deliver value through thoughtful implementation. Happy scripting!