Managing Change Requests in ServiceNow: A Comprehensive Guide

By /






Mastering Change Requests in ServiceNow: A Human-Centric Guide


Mastering Change Requests in ServiceNow: A Human-Centric Guide

Hey there, fellow ServiceNow enthusiast! Ever felt like navigating the world of IT change can be a bit like herding cats? You’re not alone. In the fast-paced realm of IT Service Management (ITSM), ensuring that changes to your infrastructure and services are controlled, tracked, and executed smoothly is paramount. That’s where ServiceNow Change Requests come into play. It’s not just a module; it’s the heart of managing evolution in your IT landscape.

From my early days tinkering with Rome, then riding the waves through San Diego, Tokyo, Utah, Vancouver, and now enjoying the crisp, efficient features of Washington DC – the latest release – I’ve seen how ServiceNow continually refines its approach to change. It’s a journey of continuous improvement, much like the changes we manage within the platform itself. This article isn’t just about what Change Requests are; it’s about how to manage them effectively, why they matter, and how to leverage ServiceNow’s capabilities to make your life a whole lot easier.

The ‘Why’ Behind Change Requests: Beyond Incidents and Problems

Before we dive deep into the mechanics of Change Requests, it’s crucial to understand their place in the broader ITSM ecosystem. Think of it as a narrative, a story of an IT service’s life.

Incident vs. Problem vs. Change: The Core Relationship

Imagine your daily work. Suddenly, something stops working. Your email client crashes, or a critical application goes offline. This sudden interruption? That’s an Incident. Its primary goal is restoration – get the service back up and running as quickly as possible. In ServiceNow, an incident is a record of something broken, and we create it often from users reporting issues. Scripting an incident creation is straightforward:

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 CI
gr.short_description = 'Test record using script';
gr.description = 'Test record using script for an antivirus issue.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
gr.insert();

Now, what if that same email client keeps crashing every Tuesday morning? Or what if multiple users are reporting the exact same application failure, perhaps not simultaneously, but over a recurring period? This persistent, underlying cause of one or more incidents? That’s a Problem. A problem aims to identify the root cause and find a permanent solution. You can absolutely create a problem record right from an incident if you see a recurring pattern. Scripting for problem creation follows a similar pattern:

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 using script';
gr.description = 'Investigating recurring antivirus issues.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();

Interview Insight: When asked about the relationship, always start with Incident, then Problem, then Change. Emphasize that a Problem identifies the root cause, and a Change implements the solution. This shows a holistic understanding of ITSM.

And finally, if the solution to that recurring email crash (our problem) requires an upgrade to the mail server’s operating system, or if the application failure needs a patch to its underlying software – that’s a Change Request. A change is a planned alteration to an IT service or infrastructure. It’s about making sure that these necessary alterations are assessed, approved, implemented, and reviewed in a controlled manner, minimizing risk and impact. Yes, you can (and often should!) create a change request directly from an incident or a problem if the solution requires a formal change.

This flow is critical: Incident -> Problem -> Change. It represents the lifecycle of addressing issues and evolving services. When a support engineer diagnoses an incident and realizes a software change is needed, they’ll raise a change request. This ensures the fix is not a quick, unchecked patch, but a properly managed alteration.

Navigating Change Requests in ServiceNow: Core Concepts

At its heart, a Change Request (CR) in ServiceNow is a record on the change_request table, guiding us through a structured process. It’s one of the many “task” tables, meaning it extends the base task table, inheriting a lot of common fields and behaviors from it, just like Incident and Problem do.

Creating a Change Request: The Workflow

Whether initiated from an Incident/Problem, a service catalog item, or manually, creating a CR kicks off a structured process. Here’s how you’d script one:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'Software'; // Example category
gr.subcategory = 'Application Upgrade'; // Example subcategory
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // The Configuration Item being changed
gr.short_description = 'Upgrade email server OS for recurring crashes';
gr.description = 'This change is necessary to resolve the root cause of INCXXXXX and PRBXXXXX, related to frequent email client crashes. Upgrading to the latest OS version will ensure stability and security.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();

Once created, a CR typically moves through states like New, Assess, Implement, Review, and Close. This structured approach, known as the Process Flow, is a visual indicator at the top of the form, showing exactly where the change stands in its lifecycle. It’s a fantastic way to quickly grasp the state of a change without digging into fields.

The Role of Users and Groups in Change Management

Effective change management isn’t just about the technical steps; it’s deeply tied to who can do what. This brings us to user and group management, a foundational aspect of ServiceNow.

Users (stored in the sys_user table) and Groups (sys_user_group for group definitions, and sys_user_grmember for group members) are your organizational backbone. You can add roles (permissions) to users directly, but the absolute best practice is to assign roles to groups, and then add users to those groups. Why? It’s simple, scalable, and secure. When an employee leaves, removing them from groups automatically revokes their roles, preventing orphaned permissions. To check if the current logged-in user is part of a specific group, you can use gs.getUser().isMemberOf('group name');.

Scripting user and group creation, and then assigning roles and memberships, is a common automation task:

// Create a User
var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.user_name = 'jdoe';
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();

// Create a Group
var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Change Approvers - Network';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the manager
newGr.email = 'network.change.approvers@example.com';
newGr.description = 'Group responsible for approving network changes.';
newGr.insert();

// Add a Role to a User (less recommended, but possible)
var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user','62826bf03710200044e0bfc8bcbe5df1'); // User's sys_id
userRole.setValue('role','2831a114c611228501d4ea6c309d626d'); // Role's sys_id
userRole.insert();

// Add a Role to a Group (BEST PRACTICE)
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group','477a05d153013010b846ddeeff7b1225'); // Group's sys_id
grpRole.setValue('role','2831a114c611228501d4ea6c309d626d'); // Role's sys_id (e.g., 'itil_admin')
grpRole.insert();

// Add a Group Member
var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // User's sys_id
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Group's sys_id
grMem.insert();

// Remove a Group Member
var grMemDel = new GlideRecord('sys_user_grmember');
grMemDel.addQuery('user','62826bf03710200044e0bfc8bcbe5df1');
grMemDel.addQuery('group','477a05d153013010b846ddeeff7b1225');
grMemDel.query();
if(grMemDel.next()){
    grMemDel.deleteRecord();
}

User Delegation is another vital feature, especially in approval-heavy processes like Change Management. If a manager who needs to approve a change is on vacation, they can delegate their approval tasks to a colleague. You set this up directly in the original user’s profile under “Delegates,” specifying the delegate, start/end dates, and which permissions (assignments, notifications, approvals) are delegated.

Permissions and Best Practices: Securing Your Changes

Who can create a change? Who can approve it? Who can close it? This is all governed by roles and Access Controls (ACLs). To work on ACLs, you need the security_admin role, which is a powerful role often requiring elevation. ACLs define what data users can access (read, write, create, delete) at the row and column level.

Interview Insight: Mentioning the security_admin role for ACLs and the best practice of group-based role assignment showcases a strong understanding of ServiceNow security.

A quick note on two crucial testing concepts: Impersonation allows you to “log in as” another user to test their experience and permissions without needing their credentials. This is invaluable when testing change workflows. Also, remember that a “Web Services User” is a special user granted access only for third-party applications to connect to ServiceNow; they cannot log in via the regular UI.

Deep Dive: Customizing and Enhancing Change Management

ServiceNow’s power lies in its flexibility. We can tailor Change Requests to fit virtually any organizational process.

Scripting for Automation: Powering Your Change Workflow

Beyond creating records, scripting in ServiceNow, primarily with GlideRecord and Business Rules, lets you automate complex logic. For instance, what happens when a Change Request is closed? Often, related records need to be updated. While the reference focuses on Incident/Problem closing, let’s adapt a common scenario for Change: preventing closure if tasks are open, and ensuring associated Problems/Incidents are closed.

Preventing Closure if Open Tasks Exist (Example for Incident, adaptable for Change Request): This is a common requirement to ensure all work related to a change is complete before it’s closed. This would typically be a “before update” Business Rule.

// On Change Request: Before Update Business Rule
// Condition: current.state.changesTo('7') (Assuming 7 is 'Closed')

var grTask = new GlideRecord('change_task'); // Assuming Change Tasks exist
grTask.addQuery('change_request', 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 Change Request because there are open tasks. Please close all associated tasks first.');
    current.setAbortAction(true);
}

Closing Associated Problems/Incidents when a Change Request is Closed: This ensures consistency across ITSM modules. This would be an “after update” Business Rule on the Change Request table.

// On Change Request: After Update Business Rule
// Condition: current.state.changesTo('7') (Assuming 7 is 'Closed')

if (current.state == '7') { // Check if the current Change Request is being closed
    // Find associated Problem records
    var grProblem = new GlideRecord('problem');
    grProblem.addQuery('rfc', current.sys_id); // Assuming 'rfc' (Request for Change) field links to Change
    grProblem.addQuery('state', '!=', '7'); // Don't update if already closed
    grProblem.query();

    while (grProblem.next()) {
        grProblem.state = '7'; // Set Problem state to Closed
        grProblem.update();

        // Now, find incidents linked to THIS problem and close them
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', grProblem.sys_id);
        grIncident.addQuery('state', '!=', '7'); // Don't update if already closed
        grIncident.query();

        while (grIncident.next()) {
            grIncident.state = '7'; // Set Incident state to Closed
            grIncident.update();
        }
    }
}

Note: The problem-to-incident closure logic from the reference is applied here, cascaded from the change. Always test such complex Business Rules thoroughly in a non-production environment!

UI Policies, Data Policies, and Dictionary Overrides: Tailoring the User Experience

The user experience on a Change Request form can be highly customized. We have several tools for this:

  • UI Policies: These client-side scripts make fields mandatory, read-only, or hidden, or control related list visibility, based on conditions. They run when the form loads (if “On Load” is checked) or when a field changes. “Reverse if false” automatically undoes the actions if the condition becomes false. “Global” applies to all views, otherwise, you specify a view. “Inherit” applies the policy to child tables. Yes, you can write scripts within a UI Policy by checking “Run scripts,” but generally, simple field manipulations are preferred here. You can even convert a UI Policy to a Data Policy (more on that next!), but not if it controls visibility, views, related lists, or custom scripts.
  • Data Policies: These are more robust, working both client-side and server-side, making fields mandatory or read-only based on conditions, ensuring data consistency across all entry points (forms, imports, web services). Unlike UI Policies, they enforce data integrity regardless of how the record is created.
  • Dictionary Overrides: Imagine you have a field, say ‘Priority’, on the parent ‘Task’ table with a default value of ‘4’. But on your ‘Change Request’ table (which extends ‘Task’), you want the default ‘Priority’ to be ‘5’. Dictionary Overrides allow you to change a field’s properties (like default value, label, mandatory status, read-only) specifically for a child table, overriding the parent’s definition.
  • Dictionary Attributes: These are small, powerful strings added to a field’s dictionary entry to alter its behavior, such as no_email, no_attachment, tree_picker. For example, to disable attachments on a form, you’d add no_attachment to the Collection record for that table (the special dictionary entry representing the table itself, stored in sys_db_object).
  • Reference Qualifiers: These filter the data shown in reference fields (e.g., limiting the Configuration Items shown for a change).
    • Simple: A fixed query (e.g., active=true for users).
    • Dynamic: Uses pre-defined dynamic filter options that adapt to context (e.g., showing CIs managed by the current user’s group).
    • Advanced (JavaScript): Custom JavaScript to build complex queries (e.g., javascript:'assignment_group=' + current.assignment_group + '^priority<3').
  • Dependent Values: Creates cascaded dropdowns, where choices in one field depend on the selection in another (e.g., Subcategory choices change based on Category).
  • Calculated Value: Allows a field's value to be automatically computed based on other field values, using a script in its dictionary entry.

You can make a field mandatory or read-only in multiple ways: Dictionary properties, Dictionary Overrides, UI Policies, Data Policies, and even client scripts (g_form.setMandatory()). However, you should generally aim for the most server-side, least impactful method first: Dictionary > Data Policy > UI Policy > Client Script. And no, you shouldn't make two fields "display" fields in one table; it leads to confusion when displaying reference records.

Tables and Fields: The Building Blocks

ServiceNow is built on a relational database, abstracted by its tables and fields. All tables are ultimately defined and stored in the sys_db_object table. When you create a new custom table, typically four basic ACLs are automatically created for it (read, write, create, delete) if the 'Create access controls' checkbox is checked.

Understanding table extension is crucial. When you extend a table (like Change Request extends Task), the child table inherits all fields from the parent. The 'sys' fields (sys_id, sys_created_on, etc.) are only physically stored once on the parent record. A 'class' field is added to the parent table to indicate its specific type (e.g., 'incident', 'problem', 'change_request'). This is how one base table (like Task) can be extended by many others, each having its unique class.

Some base tables, like task and cmdb_ci, don't extend any other tables but are extended by many. Examples of tables extending task include Incident, Problem, and Change Request.

Field types are diverse: Reference, String, List, Choice, Email, Date/Time, Date, Boolean, Integer, Journal, Attachment are just a few. When creating a number field (like 'INC0001001'), you configure a prefix and digit count in the table's "Controls" tab, ensuring "Auto-number" is checked.

Relationships between tables are also vital:

  • One-to-Many: Think Users and Incidents (one user, many incidents).
  • Many-to-Many: Incidents and Groups (one incident can involve many groups, one group can handle many incidents).

Interview Insight: Be ready to rattle off field types and explain table extension. This demonstrates foundational knowledge.

Finally, remember you can create records in many ways: directly via the form, using Record Producers (for catalog items), through email, via GlideRecord scripting, imports from Excel, and integrations with external systems.

Troubleshooting Common Change Management Issues

Even with the best processes, things can sometimes go awry. Here are a few common issues and troubleshooting tips:

Change Approval Not Triggering:

  • Check Approval Rules: Ensure your approval definitions (Approval Policies, Workflow activities, or Business Rules) are correctly configured and the conditions for the approval to trigger are met.
  • User/Group Availability: Is the designated approver active? Are they part of the correct group? Is their delegation set up correctly if they're out?
  • Workflow Context: If using a workflow, check the workflow context for errors or stuck activities.
  • ACLs: Does the approver have the necessary roles to see and approve the change?

Fields Not Displaying/Editable as Expected:

  • UI Policies/Client Scripts: Check for conflicting UI Policies or Client Scripts that might be hiding or disabling the field. Use the Field Watcher or Browser Developer Tools.
  • Data Policies: Ensure a Data Policy isn't making the field read-only or mandatory unexpectedly.
  • Dictionary Overrides: Verify if a Dictionary Override is altering the field's behavior on the Change Request table.
  • ACLs: A user might not have 'read' or 'write' access to the field due to an ACL. Impersonate the user and check Field Watcher.

Scripting Errors in Business Rules (e.g., for auto-closing related records):

  • Logs: Always use gs.info() or gs.debug() statements in your scripts to track execution flow and variable values. Check System Logs.
  • Conditions: Double-check Business Rule conditions (When to run, conditions tab) to ensure it's firing at the correct time (before/after insert/update/delete).
  • GlideRecord Queries: Verify your GlideRecord queries. Are you querying the correct table? Are your addQuery conditions precise? Are you calling .query() and iterating with .next() where appropriate?
  • Field Names: Ensure all field names (e.g., current.state, grProblem.rfc) are correct.

Interview Readiness: Acing ServiceNow Change Management Questions

Navigating a ServiceNow interview often involves demonstrating practical knowledge. Here's how to frame some of the insights we've discussed:

  • "What's the relationship between Incident, Problem, and Change?" (Q29): Explain the flow: Incident (restoration) -> Problem (root cause) -> Change (permanent solution). Emphasize control and risk mitigation for Change.
  • "How do you ensure data integrity for a field on the Change Request form?" (Q42, Q66): Talk about Data Policies for server-side enforcement across all data sources, and UI Policies for client-side form behavior. Mention Dictionary Overrides for specific child table behavior.
  • "What's a best practice for assigning roles in ServiceNow?" (Q3): Group-based role assignment, always. Explain why (scalability, ease of management, security upon user departure).
  • "Explain Reference Qualifiers." (Q48): Define them as filtering mechanisms for reference fields. Explain Simple, Dynamic, and Advanced with small examples.
  • "How would you prevent a Change Request from being closed if there are open tasks?" (Q27): Describe a "before update" Business Rule on the Change Request table that checks for related open tasks and uses current.setAbortAction(true) and gs.addErrorMessage().

Staying Current: ServiceNow Versions and UI

Our Journey Through ServiceNow Versions

My own journey started with Rome, a solid foundation, and I've worked my way through San Diego, Tokyo, Utah, and Vancouver. Each release brought its own set of enhancements, new features, and performance improvements. Today, we're on Washington DC, the latest release, which continues to push the boundaries of platform capabilities, automation, and user experience. Staying up-to-date with these releases is crucial for any ServiceNow professional to leverage the newest features and maintain optimal performance.

The Evolving User Interface

ServiceNow has always been committed to improving the user experience. We've seen the evolution from the classic UI15 and UI16 to the modern Next Experience UI. The Next Experience UI, introduced more broadly in recent versions, provides a more intuitive, personalized, and efficient workspace, streamlining navigation and task management. It's a significant leap forward, making complex processes like Change Management more accessible and user-friendly.

Conclusion

Managing Change Requests in ServiceNow is more than just logging tickets; it's about orchestrating controlled evolution within your IT environment. It’s about understanding the delicate dance between Incidents, Problems, and Changes, and leveraging ServiceNow’s robust features to automate, customize, and secure your processes. From the fundamental relationships of ITSM modules to the intricate details of scripting, UI policies, and permissions, a deep dive into Change Management reveals the true power and flexibility of the ServiceNow platform.

So, whether you're a seasoned admin, a developer crafting intricate workflows, or someone just starting your journey through ServiceNow's capabilities, mastering Change Requests is a vital skill. It’s about building a stable, predictable, and responsive IT landscape – and that, my friends, is a change worth making!


Scroll to Top