Mastering Real Change Request Scenarios

By /






From Incident to Innovation: Mastering ServiceNow Through a Live Change Request Scenario


From Incident to Innovation: Mastering ServiceNow Through a Real Change Request Scenario

Ever found yourself staring at a blank form, tasked with implementing a critical system change, and wondering where to even begin? Or perhaps you’re just starting your journey with ServiceNow and feel overwhelmed by the sheer number of interconnected concepts? You’re not alone. The beauty—and sometimes the beast—of ServiceNow lies in its comprehensive integration. Today, we’re not just going to scratch the surface; we’re diving deep into a realistic Change Request scenario, weaving together essential concepts that every ServiceNow professional, from fresh-faced newbie to seasoned veteran, needs to master.

Think of it as a guided tour through the ServiceNow galaxy, currently powered by the Washington DC release – the latest one, for those keeping score. We’ll trace the lifecycle of a change, from its humble beginnings as a recurring problem to its eventual implementation, touching on everything from user permissions to the underlying data architecture. Ready to roll up your sleeves?

Section 1: Setting the Stage – The Lifecycle of a Change

Every significant alteration in an IT environment usually starts with a catalyst. Often, that catalyst is an IT Service Management (ITSM) event. Let’s imagine a scenario:

Our company’s critical reporting service keeps failing every Tuesday morning, causing significant delays. Users are frustrated, and the IT helpdesk is swamped.

From Incident to Problem to Change: The ITSM Flow

This scenario perfectly illustrates the interconnected dance between Incident, Problem, and Change Management, core pillars of ITSM within ServiceNow. Here’s how it typically unfolds:

  • The Incident: When that reporting service first stops working, users will inevitably flood the helpdesk. Each call, each email, each chat message about the service being down triggers an Incident. An incident is a sudden interruption to a service. Its primary goal is to restore service as quickly as possible.
  • The Problem: If this “reporting service down” issue keeps cropping up – say, every Tuesday for three weeks straight – it stops being just a series of isolated incidents. It becomes a Problem. A problem is the underlying cause of one or more incidents. The goal here is to find and eliminate the root cause, preventing future incidents. If multiple people face the same issue concurrently, it’s typically handled as one parent incident with several child incidents. Interviewers often ask: “What is the difference between an Incident and a Problem?” or “Can we create a Problem from an Incident?” (Yes, if the issue recurs!).
  • The Change Request: Now, let’s say our problem investigators discover the reporting service’s database is hitting a capacity limit every Tuesday morning due to an outdated configuration. Fixing this root cause isn’t a quick patch; it requires a Change to the production environment. A change request is a formal proposal for an alteration to an IT service or infrastructure. This is where our main story begins. Another common question: “Can we create a Change Request from an Incident/Problem?” (Absolutely! This is a best practice for planned remediation).

The relationship is clear: An Incident signals something is broken. A Problem diagnoses why it’s broken. A Change Request proposes how to fix it permanently or implement an improvement. This ensures structured, risk-managed alterations.

Scripting ITSM Records: The Power of GlideRecord

In ServiceNow, automating the creation of these records is a common requirement. Imagine a monitoring tool detecting an outage and automatically creating an incident. This is where GlideRecord comes into play, a powerful server-side API for interacting with the database.

Creating an Incident via script:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus'; // Example, actual might be 'Database' or 'Reporting'
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the affected Configuration Item
gr.short_description = 'Reporting Service down every Tuesday morning';
gr.description = 'Reporting database reaching capacity limits, causing service interruption.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the Assignment Group
gr.insert();

Similarly, for a Problem record:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Root cause: Database capacity issue for Reporting Service';
gr.description = 'Investigation shows database hitting peak capacity. Requires configuration change.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();

And for our main focus, the Change Request:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'standard'; // Or normal, emergency depending on type
gr.subcategory = 'database_config';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Increase reporting database capacity limits';
gr.description = 'Modify database configuration parameters to prevent capacity overruns affecting reporting service.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();

Remember: For reference fields like caller_id, cmdb_ci, and assignment_group, you always provide the sys_id of the referenced record when using setValue() or direct assignment with GlideRecord.

Section 2: Building Blocks – Users, Groups, and Permissions

A change request, once created, doesn’t implement itself. It requires people: the requester, the implementer, the approver, and various stakeholders. Managing these individuals and their access is paramount, and ServiceNow provides robust mechanisms for this.

Who’s Who in the ServiceNow Zoo?

At the heart of user management is the User table (sys_user). This is where every individual with access to your ServiceNow instance lives. And for organizing them, we have the Group Member table (sys_user_group), which links users to their respective groups.

From an interview perspective, knowing the table names like sys_user and sys_user_group is a basic expectation. But understanding how to manage them efficiently is what really sets you apart.

The Golden Rule: Assign Roles to Groups, Not Users

When it comes to giving people permissions (called roles in ServiceNow), there’s a golden rule: always add roles to groups, and then add users to those groups.

Why? Best practice, plain and simple. Imagine a project team of 50 people. If you assign 10 roles to each of them individually, that’s 500 role assignments to manage. When someone leaves, you have to find and remove all 10 roles. If roles are assigned to a group, you just remove the user from the group, and all their group-inherited roles disappear automatically. It’s cleaner, more scalable, and reduces errors.

This is a classic interview question: “Can we add permissions to users and groups? Which is the best practice?”

Scripting User and Group Creation

Automating user and group creation is incredibly useful for integrations with HR systems or bulk onboarding. Again, GlideRecord is our friend.

To create a User Account:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username='jdoe';
userGr.first_name='John'; // Note: field name is first_name
userGr.last_name = 'Doe';  // Note: field name is last_name
userGr.email = 'jdoe@example.com';
userGr.insert();

To create a Group:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name='Reporting Service Admins';
newGr.manager='62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the manager user
newGr.email='report-admins@example.com';
newGr.description='Admins for the critical reporting service.';
newGr.insert();

Assigning Roles (Permissions) with Scripts

When you assign a role to a user, a record is created in the sys_user_has_role table. For groups, it’s the sys_group_has_role table. Knowing these tables is key for scripted assignments or troubleshooting.

Adding a Role to a User (though remember the best practice is groups!):

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 (the best practice!):

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();

Managing Group Membership Programmatically

Adding or removing users from groups is just as crucial. The sys_user_grmember table handles these associations.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
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');
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225');
grMem.query();
if(grMem.next()){
    grMem.deleteRecord();
}

Special User Scenarios: Delegation, Impersonation, and Web Services Users

  • User Delegation: Sometimes, people go on vacation. In our change request scenario, what if the crucial approver for the database change is out for two weeks? User delegation allows one user to act on behalf of another, typically for approvals or tasks. You can configure this directly from the original user’s profile under the “Delegates” related list, specifying the delegate, start/end dates, and what permissions are delegated (assignments, notifications, approvals).
  • Impersonation: As developers or administrators, we frequently need to test functionalities as if we were a different user. This is where impersonation comes in. It lets you “log in” as another user (for testing purposes only) without knowing their password. This is invaluable for troubleshooting UI policies, ACLs, or workflow approvals.
  • Web Services User: For third-party applications needing to interact with ServiceNow (e.g., our monitoring tool creating incidents), a dedicated Web Services User is often used. This user account is typically granted specific roles for API access but cannot log in to the ServiceNow UI as a regular user. It’s a security best practice for integrations.
  • Security Admin Role: To work on critical security configurations like Access Control Lists (ACLs), you need the powerful security_admin role. This role is often elevated temporarily to perform sensitive tasks.

Current User Details: Client vs. Server Side

Knowing who the currently logged-in user is, and their properties, is essential for dynamic scripting.

  • Client-side (Browser): Use g_user.userID to get the sys_id of the current user. E.g., alert(g_user.userID);
  • Server-side (Business Rules, Script Includes): Use gs.getUserID() to get the sys_id of the current user. You can also check group membership with gs.getUser().isMemberOf(‘group name’), which returns true if the user is part of the specified group.

Distinguishing client-side (g_form, g_user) from server-side (gs, current) is a fundamental interview question.

Section 3: The Data Layer – Tables, Fields, and Their Magic

Behind every form and every record in ServiceNow lies a table, meticulously structured with fields. Understanding this foundation is crucial for any customization, including our change request.

Exploring ServiceNow’s Data Model

  • Out-of-the-Box (OOTB) Tables: These are the tables that come pre-built with ServiceNow, like incident, problem, change_request, sys_user. They don’t start with prefixes like x_ (for scoped apps) or u_ (for custom tables).
  • Base Tables: Some tables don’t extend other tables but are extended by many. Think of them as foundational pillars. Task (task) and Configuration Item (cmdb_ci) are prime examples.
  • Task Tables: Many core ITIL processes extend the task table. This includes incident, problem, and change_request. This inheritance means they share common fields and functionalities, promoting consistency.

Expect questions like: “Name some OOTB tables,” “What are base tables?”, or “Give examples of tables extending the Task table.”

Creating Tables and Fields: Under the Hood

When you create a new custom table in ServiceNow, several things happen:

  • By default, 4 Access Control Lists (ACLs) are automatically created for that table (create, read, write, delete). You can uncheck this option during creation if you prefer to build your own.
  • To get an auto-incrementing number field, like INC0001001, you configure this in the Control tab of the table definition, setting a prefix and the number of digits.
  • When you extend a table, the child table inherits all fields from the parent. Crucially, the system fields (like sys_id, sys_created_on) are not *re-created* in the child table; they are simply inherited. A special field called class is added to the parent table to differentiate between records of different child tables. Even if a table extends multiple levels deep, there’s only one class field in the top-most parent.
  • All tables in ServiceNow are ultimately stored and managed within the sys_db_object table.

Field Types: Your Data’s Personality

ServiceNow offers a wide array of field types to store different kinds of data. Here are 10 common ones:

Reference, String, List, Choice, Email, Date/Time, Date, Boolean, Integer, Journal, Attachment.

Table Variations: Temporary, Remote, and Relationships

  • Temporary vs. Normal Tables: Temporary tables store data for a short period (default 7 days) and typically extend the import_set_row table. They’re great for transient data like import set staging. Normal tables store data permanently. You can increase the retention period of temporary tables using archive rules.
  • Remote Tables: These tables provide a live view of data residing in an external system, without actually storing the data within ServiceNow. This is different from normal tables, which hold their own data.
  • Table Relationships:
    • One-to-Many: A common relationship, e.g., one user can have multiple incidents, but each incident is assigned to only one user.
    • Many-to-Many: When records from two tables can be associated with multiple records from the other, e.g., an incident can be associated with multiple configuration items, and a CI can be linked to multiple incidents.

Controlling Field Behavior: Dictionary Attributes and Overrides

  • Default Values: You can set a default value for any field that will automatically populate when a new record form is opened. This is configured in the field’s dictionary entry.
  • Calculated Values: If a field’s value needs to be dynamically computed based on other field values, you can use a calculated dictionary property. This runs server-side via a script.
  • Attributes: These are powerful modifiers that change a field’s behavior at the dictionary level. Examples include no_email (prevents field value from being sent in notifications), no_attachment (disables attachments on a specific record type), no_add_me (prevents current user from being added to a reference list), tree_picker (for hierarchical selection).
  • Collection Field: Every table has a special dictionary entry of type ‘Collection’. Changes to this entry (like adding a no_attachment attribute) apply to the entire table, not just a specific field. This is how you enable/disable attachments globally for a form.
  • Dictionary Overrides: A lifesaver for inherited fields! Use a dictionary override to make a field behave differently in a child table compared to its parent. For instance, if the ‘Priority’ field’s default value is ‘4’ on the Task table, you could override it to ‘5’ for the Incident table. You can override properties like default value, mandatory status, read-only, choice list values, and reference qualifiers.

Refining Data Selection: Reference Qualifiers and Dependent Fields

In our change request, we might want the “Configuration Item” field to only show active CIs that are part of the ‘Reporting Service’. This is where Reference Qualifiers shine:

  • Simple Reference Qualifier: A fixed query string to filter results. Example: active=true^install_status=1 (show only active, installed CIs).
  • Dynamic Reference Qualifier: Uses a predefined dynamic filter option. This is good when you want to reuse a complex, context-aware filter (e.g., “Assigned to my groups”).
  • Advanced Reference Qualifier (JavaScript): The most flexible. You write a JavaScript function that returns a query string. This allows for complex logic based on other form fields or the current user. Example: javascript: 'assignment_group=' + current.assignment_group + '^priority<3'

Understanding the types of reference qualifiers and their differences (especially simple vs. advanced) is a common deep-dive question.

Dependent Values: To create cascading dropdowns (e.g., selecting 'Hardware' in 'Category' then only seeing 'Laptop', 'Desktop' in 'Subcategory'), you use dependent values. You define choices for the dependent field (Subcategory) that are linked to specific values of the parent field (Category). This ensures context-sensitive selections.

Section 4: Orchestrating the UI & Business Logic – Policies, Rules, and Automation

Once the data model is sound and user access is sorted, it's time to ensure the forms guide users correctly and that critical business rules are enforced. This is where UI policies, data policies, and business rules come into play.

User Experience: UI Versions and Preferences

  • User Interfaces: ServiceNow has evolved its UI significantly. You might encounter UI15, UI16, and the newer Next Experience. Each aims to improve usability and efficiency.
  • User Preferences: Users can personalize their experience (e.g., list layout, date format). These changes are stored as user preferences and only impact that specific user, not the entire system.

Form Flow and Navigation

  • Application Menus & Modules: To make our change request form and its associated lists accessible to end-users, we define Application Menus (like "Change") and Modules (like "Create New" or "All Changes") that appear in the left navigation pane.
  • Process Flow: The visual indicator at the top of forms, like a change request, showing its current state (New, Assess, Implement, Review, Closed) is called the Process Flow. It guides users through the workflow.
  • Data Lookup Rules: These allow you to automatically populate field values on a form based on values in other fields, often referencing a separate lookup table. For instance, populating the 'Priority' and 'Assignment Group' based on 'Category' and 'Subcategory' values.

Controlling the Form: UI Policies vs. Data Policies

Making fields mandatory, read-only, or hidden based on conditions is a common requirement. You have two main tools for this:

  • UI Policies:
    • Purpose: Primarily for client-side form manipulation (making fields mandatory, read-only, visible/hidden, showing/hiding related lists). They improve user experience dynamically.
    • Global Checkbox: If checked, the UI Policy applies to all views. Unchecked, you specify a particular view.
    • Reverse if False: If checked, when the condition is no longer met, the actions are reversed (e.g., a mandatory field becomes optional again).
    • On Load: If checked, the UI Policy runs when the form initially loads. If unchecked, it only triggers when a field changes, and the condition is met.
    • Inherit Checkbox: If checked, the UI Policy also applies to tables extending the current table.
    • Scripting: Yes, you can write scripts in a UI Policy by checking the 'Run scripts' box, allowing for more complex client-side logic.
  • Data Policies:
    • Purpose: Enforce data integrity across all data entry methods (form, import sets, web services, scripts). They work on both client and server sides.
    • UI Policy to Data Policy: You can convert a UI Policy into a Data Policy if its primary purpose is data integrity, not just UI presentation. However, you cannot convert a UI Policy to a Data Policy if it's controlling data visibility, views, related lists, or running scripts, as these are UI-specific functions.

When making a field mandatory or read-only, the order of precedence is: ACLs > Data Policies > Dictionary Overrides > UI Policies > Client Scripts. This is a critical piece of knowledge for troubleshooting!

Enforcing Business Logic: Business Rules

For server-side automation and enforcement of complex logic, Business Rules are your go-to. Let's look at some examples relevant to our ITSM flow:

Scenario 1: Closing Child Incidents when Parent Closes

When our parent incident (for the reporting service outage) is closed, we want all related child incidents to close automatically. This is a perfect candidate for an After Update Business Rule.

// Business Rule: Close Child Incidents
// When: After, Update
// Condition: current.state.changesTo(7) && current.parent == '' // 7 typically means 'Closed'

if (current.state == 7 && current.parent == '') {
    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 2: Preventing Record Closure with Open Tasks

In our change request scenario, if the change has associated tasks (e.g., "update database config," "test reporting service") and these tasks are not yet closed, the change request itself should not be closed. This is a common requirement for Incidents, Problems, and Change Requests.

This would be a Before Update Business Rule (or a workflow validation) on the respective table:

// Business Rule: Prevent Incident Closure if Tasks Open
// When: Before, Update
// Condition: current.state.changesTo(7) // If trying to close (state 7)

var grTask = new GlideRecord('incident_task'); // Change to 'problem_task' or 'change_task' for other tables
grTask.addQuery('incident', current.sys_id);   // Change 'incident' to 'problem' or 'change_request'
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close this record because there are open tasks.');
    current.setAbortAction(true); // Prevents the update from saving
}

Scenario 3: Closing Incidents Associated with a Closed Problem

Once our problem (the database capacity issue) is permanently resolved and closed, any incidents linked to it should also be closed automatically.

// Business Rule: Close Associated Incidents on Problem Closure
// When: After, Update
// Condition: current.state.changesTo(7) // If problem is closed

if (current.state == 7) {
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id);
    grIncident.addQuery('state', '!=', 7); // Don't re-close already closed incidents
    grIncident.query();

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

These Business Rule scenarios are gold for interviews, demonstrating practical scripting and understanding of ITSM workflows.

Conclusion: The Symphony of ServiceNow

From the initial flicker of an incident to the methodical execution of a change request, we've journeyed through a significant portion of the ServiceNow platform. We've explored how user access is controlled, how data is structured and modified, and how the user interface is made intelligent and efficient.

Whether you're creating users with GlideRecord, fine-tuning form behavior with UI Policies, enforcing data integrity with Data Policies, or automating workflows with Business Rules, each piece plays a vital role in the grand symphony of ServiceNow. Mastering these concepts isn't just about memorizing facts; it's about understanding their interplay, knowing the best practices, and applying them intelligently to solve real-world IT challenges.

The beauty of ServiceNow lies in its ability to connect these dots seamlessly, transforming complex processes into manageable, transparent workflows. Keep exploring, keep building, and remember: every change request is an opportunity to learn something new about this powerful platform!


Scroll to Top