Mastering ServiceNow CMDB: Top 10 Scenarios and How to Tackle Them

The ServiceNow Configuration Management Database (CMDB) is the heart of many IT Service Management (ITSM) processes. It provides a single source of truth for your IT infrastructure, dependencies, and relationships, enabling better decision-making, faster incident resolution, and more efficient change management. But effectively leveraging the CMDB often involves understanding and implementing specific scenarios. In this in-depth article, we’ll walk through ten critical CMDB scenarios, providing practical explanations, code snippets, and insights that will boost your ServiceNow proficiency. Whether you’re a seasoned administrator or just starting, this guide is designed to be your go-to resource.

1. Programmatically Creating Incidents Tied to a CI

One of the most common tasks in ServiceNow is creating records via scripts, especially when automating processes or integrating with other systems. When an issue arises with a specific piece of hardware or software, it’s crucial to link the incident directly to that Configuration Item (CI) within the CMDB. This linkage provides immediate context for the support team.

Imagine you have a monitoring tool that detects a critical error on a specific server. You want to automatically create an incident in ServiceNow and link it to that server CI. This is where scripting becomes invaluable.

Solution: Using GlideRecord for Incident Creation

The GlideRecord API is your best friend for manipulating records in ServiceNow. Here’s how you can create an incident and associate it with a CI:

    // Define the CI sys_id you want to link to
    var ciSysId = 'affd3c8437201000deeabfc8bcbe5dc3'; // Replace with the actual sys_id of your CI

    // Create a new GlideRecord object for the incident table
    var grIncident = new GlideRecord('incident');
    grIncident.initialize(); // Initialize a new incident record

    // Set essential fields for the incident
    grIncident.caller_id = '86826bf03710200044e0bfc8be5d94'; // sys_id of the caller
    grIncident.category = 'inquiry'; // Example category
    grIncident.subcategory = 'antivirus'; // Example subcategory
    grIncident.cmdb_ci = ciSysId; // Link to the specific CI
    grIncident.short_description = 'Automated Incident: Server experiencing critical errors';
    grIncident.description = 'A monitoring alert triggered an automated incident creation for the server.';
    grIncident.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group

    // Insert the new incident record into the database
    var incidentSysId = grIncident.insert();

    // Optional: Log a confirmation message
    gs.info('Incident ' + grIncident.number + ' created successfully for CI: ' + ciSysId);
    

2. Programmatically Creating Problem Records Tied to a CI

Problem Management aims to identify the root cause of recurring incidents. When a pattern of incidents emerges, creating a problem record and linking it to the affected CI is a critical step. This allows teams to investigate the underlying issue without being overwhelmed by individual incident tickets.

If multiple similar incidents are reported, a support agent might decide to create a Problem record to investigate the root cause. This can also be automated based on certain criteria.

Solution: Using GlideRecord for Problem Creation

Similar to incident creation, you’ll use GlideRecord to create a problem record and link it to the relevant CI:

    // Define the CI sys_id for the problem
    var ciSysId = 'affd3c8437201000deeabfc8bcbe5dc3'; // Replace with the actual sys_id of your CI

    // Create a new GlideRecord object for the problem table
    var grProblem = new GlideRecord('problem');
    grProblem.initialize(); // Initialize a new problem record

    // Set essential fields for the problem
    grProblem.caller_id = '86826bf03710200044e0bfc8be5d94'; // sys_id of the caller
    grProblem.category = 'inquiry'; // Example category
    grProblem.subcategory = 'antivirus'; // Example subcategory
    grProblem.cmdb_ci = ciSysId; // Link to the specific CI
    grProblem.short_description = 'Root Cause Analysis: Recurring Antivirus Issues on Server';
    grProblem.description = 'Investigating the recurring antivirus alerts and related incidents.';
    grProblem.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group

    // Insert the new problem record
    var problemSysId = grProblem.insert();

    // Optional: Log a confirmation message
    gs.info('Problem ' + grProblem.number + ' created successfully for CI: ' + ciSysId);
    

3. Programmatically Creating Change Requests Tied to a CI

Change Management ensures that all changes to the IT environment are carried out in a controlled manner, minimizing disruption. When a problem is resolved, or a new feature is to be deployed, a Change Request is created. Linking this change to the affected CI is paramount for tracking and impact analysis.

Suppose a problem record has been investigated, and the solution involves a software update on a specific server. A Change Request needs to be created, clearly stating what needs to be changed and on which CI.

Solution: Using GlideRecord for Change Request Creation

Again, GlideRecord is the tool for this job. Here’s how to script a Change Request creation:

    // Define the CI sys_id for the change
    var ciSysId = 'affd3c8437201000deeabfc8bcbe5dc3'; // Replace with the actual sys_id of your CI

    // Create a new GlideRecord object for the change_request table
    var grChange = new GlideRecord('change_request');
    grChange.initialize(); // Initialize a new change request record

    // Set essential fields for the change request
    grChange.category = 'inquiry'; // Example category
    grChange.subcategory = 'antivirus'; // Example subcategory
    grChange.cmdb_ci = ciSysId; // Link to the specific CI
    grChange.short_description = 'Implement Antivirus Software Update on Server';
    grChange.description = 'Applying the latest antivirus definitions and software update to resolve recurring alerts.';
    grChange.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group

    // Insert the new change request record
    var changeSysId = grChange.insert();

    // Optional: Log a confirmation message
    gs.info('Change Request ' + grChange.number + ' created successfully for CI: ' + ciSysId);
    

4. Automatically Closing Child Incidents When a Parent Incident is Closed

In ServiceNow, an incident can have a parent-child relationship. This is often used when a major incident occurs, and several related minor incidents are created. It’s a best practice to ensure that when the overarching parent incident is resolved and closed, all its associated child incidents are also automatically closed.

When a major outage is resolved, and the parent incident is marked as ‘Closed’, it’s logical to automatically close all the linked child incidents to signify that the entire issue has been addressed.

Solution: After Business Rule on Incident Closure

A server-side Business Rule is the ideal mechanism for this. We’ll set it up to trigger after an incident is updated.

    // Business Rule Configuration:
    // Table: Incident
    // When: after
    // Update: checked
    // Condition: current.state.changesTo(7) && current.parent == ''

    // Script:
    if (current.state == 7 && current.parent == '') { // Assuming state '7' represents '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
            gs.info('Child Incident ' + grChild.number + ' closed automatically due to parent closure.');
        }
    }
    

Explanation:

• The rule triggers after an incident is updated.
• The condition ensures it only runs when the incident’s state changes to ‘Closed’ (assuming state value 7 is ‘Closed’) AND if the incident has no parent (i.e., it *is* a parent incident).
• The script then queries for all incident records where the parent field matches the sys_id of the current (parent) incident.
• For each child incident found, its state is set to ‘Closed’, and the record is updated.

5. Preventing Incident Closure if Associated Tasks are Open

It’s a common requirement that an incident cannot be closed until all its associated tasks are completed. This ensures that all necessary work is done before the incident is marked as resolved.

A support team member tries to close an incident, but there are still open incident tasks assigned to various teams. The system should prevent the closure and notify the user why.

Solution: Before Business Rule on Incident Update

A Before Business Rule on the incident table is suitable here. It will run before the incident is saved, allowing us to abort the action if conditions aren’t met.

    // Business Rule Configuration:
    // Table: Incident
    // When: before
    // Update: checked
    // Condition: current.state.changesTo(7) // Assuming state '7' is 'Closed'

    // Script:
    if (current.state == 7) { // Check if the incident is attempting to close
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id);
        grTask.addQuery('state', '!=', 3); // Assuming state '3' is 'Closed' for incident tasks
        grTask.query();

        if (grTask.hasNext()) {
            gs.addErrorMessage('Cannot close the incident because there are open incident tasks. Please complete all tasks before closing the incident.');
            current.setAbortAction(true); // Prevent the incident from being closed
        }
    }
    

Explanation:

• This Before Business Rule triggers just before an incident is updated.
• The condition specifies that it should run when the incident’s state is changing to ‘Closed’.
• The script queries the incident_task table for tasks related to the current incident.
• It checks if any of these tasks are NOT in a ‘Closed’ state (assuming state value 3 is ‘Closed’ for tasks).
• If open tasks are found, an error message is displayed to the user using gs.addErrorMessage(), and current.setAbortAction(true) prevents the incident from being saved (i.e., closed).

6. Automatically Closing Incidents When a Problem is Closed

When a Problem record is closed, it implies that the root cause has been identified and resolved. Consequently, all incidents that were linked to this problem should also be automatically closed, reflecting the resolution of the underlying issue.

After a thorough investigation, a Problem record is resolved and marked as ‘Closed’. All related incidents that were created due to this problem should also be closed, indicating that the overarching issue has been fixed.

Solution: After Business Rule on Problem Closure

An After Business Rule on the problem table is the right approach.

    // Business Rule Configuration:
    // Table: Problem
    // When: after
    // Update: checked
    // Condition: current.state.changesTo(7) // Assuming state '7' is 'Closed'

    // Script:
    if (current.state == 7) { // Check if the problem is attempting to close
        // GlideRecord to find incidents associated with the problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Assuming 'problem_id' is the field linking incident to problem
        grIncident.addQuery('state', '!=', 7); // Assuming state '7' is 'Closed' for incidents
        grIncident.query();

        while (grIncident.next()) {
            grIncident.state = 7; // Set the state to Closed
            grIncident.update(); // Update the incident
            gs.info('Incident ' + grIncident.number + ' closed automatically due to Problem ' + current.number + ' closure.');
        }
    }
    

Explanation:

• This After Business Rule runs after a problem record is updated.
• The condition ensures it triggers when the problem state changes to ‘Closed’.
• The script queries the incident table for incidents linked via the problem_id field to the current problem.
• It specifically looks for incidents that are *not* already closed.
• For each found incident, the state is set to ‘Closed’, and the incident record is updated.

7. Understanding the Relationship Between Incident, Problem, and Change Management

The interplay between Incident, Problem, and Change Management is fundamental to ITIL best practices. Understanding their roles and how they connect is crucial for effective service delivery.

A user reports a recurring issue with a specific application feature. How do Incident, Problem, and Change Management processes handle this?

Explanation:

The relationship is sequential and purpose-driven:

• Incident Management: When a user experiences an issue (e.g., an application is slow or throwing errors), they (or a help desk agent) create an Incident. The primary goal of Incident Management is to restore normal service operation as quickly as possible, even if the root cause is unknown. The CI related to the incident is logged for context.
• Problem Management: If the same incident occurs repeatedly, or if multiple incidents point to a common underlying cause, a Problem record is created. The goal of Problem Management is to identify the root cause of one or more incidents and propose a solution or workaround. This process moves beyond restoring service to preventing recurrence. The problem record will likely be linked to the affected CI(s).
• Change Management: Once the root cause of a problem is identified, a solution might involve making changes to the IT infrastructure. This could be a software patch, a configuration update, or a hardware replacement. A Change Request is then created to formally manage and execute this change, ensuring it’s assessed, approved, scheduled, and implemented with minimal risk. This change is directly linked to the CI that needs modification.

In essence: A recurring incident leads to a problem investigation, which may result in a change request to fix the root cause.

8. Identifying Out-of-the-Box (OOTB) Tables in ServiceNow

ServiceNow provides a robust set of pre-built tables that form the foundation of its applications. Understanding what constitutes an “out-of-the-box” table is essential for distinguishing between core ServiceNow functionality and custom-developed components.

When developing or troubleshooting in ServiceNow, you often need to know if you’re working with a table provided by ServiceNow itself or one that your organization has created.

Explanation:

Out-of-the-Box (OOTB) Tables: These are tables that are part of the core ServiceNow platform and are installed with any ServiceNow instance. They do not start with x_ or u_. Examples include:

• incident
• problem
• change_request
• sys_user
• cmdb_ci
• task

Custom Tables: Tables created by an organization.

• Scoped Applications: Tables created within a scoped application typically start with x_ followed by the application scope prefix and table name (e.g., x_myorg_myapp_mytable).
• Global Applications (legacy or un-scoped): Tables created directly in the global scope often start with u_ (e.g., u_mycustomtable).

Why it matters: OOTB tables are managed by ServiceNow, and their structure is generally stable. Custom tables are owned by your organization, offering flexibility but also requiring careful management.

9. Understanding Base Tables and Their Inheritance

ServiceNow uses an object-oriented approach to database design, with tables inheriting fields and functionalities from parent tables. Understanding “base tables” helps in comprehending this inheritance model and how different records share common attributes.

Why do Incident, Problem, and Change Request records all have fields like ‘Number’, ‘Short Description’, ‘Assigned To’, and ‘State’?

Explanation:

Base Tables: These are tables that do not extend any other table themselves but are extended by many other tables. They serve as foundational elements in the ServiceNow data model, providing common attributes and behaviors.

• task table: This is a classic example of a base table. Tables like incident, problem, change_request, sc_task (Service Catalog Task), and others all extend the task table. This means they automatically inherit fields such as number, short_description, description, state, assigned_to, assignment_group, opened_at, closed_at, etc.
• cmdb_ci table: This is the base table for all Configuration Items (CIs) in the CMDB. Tables like cmdb_ci_computer, cmdb_ci_server, cmdb_ci_application, etc., extend cmdb_ci. This inheritance allows for common CI attributes like name, serial_number, location, and relationships to be managed consistently.

Example of Extension:

When you create an Incident, it inherits properties from the task table. So, even though you might only explicitly define a few fields on the incident table, it automatically gets all the fields from its parent, task.

10. Understanding One-to-One, One-to-Many, and Many-to-Many Relationships

Data relationships are the backbone of any relational database. In ServiceNow, understanding how tables are connected through these relationships is vital for building effective forms, reports, and integrations.

How can you model the association between users and the incidents they report, and how can an incident be supported by multiple teams?

Explanation:

These relationships are primarily defined by the type of field used to link tables:

One-to-Many Relationship

Definition: One record in Table A can be associated with zero or more records in Table B, but each record in Table B is associated with only one record in Table A.

Example: Users and Incidents

• Users (Table A): One user can create and own many incidents.
• Incidents (Table B): Each incident is typically reported by (or assigned to) only one user (e.g., the caller_id or assigned_to field on the incident table).

How it’s implemented: A reference field on the “many” side pointing to the “one” side. For example, the caller_id field on the incident table is a reference to the sys_user table.

Many-to-Many Relationship

Definition: One record in Table A can be associated with zero or more records in Table B, AND one record in Table B can be associated with zero or more records in Table A.

Example: Incidents and Groups

• Incidents (Table A): An incident might require support from multiple specialized groups (e.g., Network team, Server team, Application team).
• Groups (Table B): A group can be responsible for multiple incidents.

How it’s implemented: This requires an intermediate “join” table. ServiceNow often uses a field that is a List type pointing to another table. For instance, an incident might have an “Affected CIs” field (a list of CIs) or multiple assignment groups associated with it through a specific relationship table.

A more direct example is the problem_task table, which links problems to tasks, and each problem can have many tasks, and each task belongs to one problem (this is actually one-to-many from Problem to Problem Task, but if we consider a task impacting multiple problems, it could become many-to-many via another joiner).

For a true many-to-many between Incidents and Groups, you might use a custom table like “Incident Groups” with fields for both incident and group.

One-to-One Relationship

Definition: One record in Table A can be associated with at most one record in Table B, and one record in Table B can be associated with at most one record in Table A.

Example: User Preferences and Users

• Users (Table A): Each user has a unique set of preferences.
• User Preferences (Table B): Each preference record belongs to only one user.

How it’s implemented: Often achieved by having a unique reference field on one table pointing to the other. For instance, a user_preference table might have a user_id field that is unique and references the sys_user table.

Beyond the Top 10: The Power of Reference Qualifiers

While not a scenario in itself, understanding Reference Qualifiers is a critical skill that underpins the effective implementation of many CMDB-related scenarios. They allow you to dynamically filter the data presented in reference fields, making your forms more intuitive and efficient.

When selecting a CI for an incident, you might only want to see CIs that are relevant to the application category selected. Or, when assigning a task, you only want to see users who are part of the selected assignment group.

Explanation: Reference Qualifiers and Their Types

Reference Qualifiers are used to restrict the data displayed in reference and list-type fields. They work by applying a query to the referenced table.

Types of Reference Qualifiers:

1. Simple Reference Qualifier

• Description: The most basic form. You specify a fixed, hardcoded query string to filter the referenced records.
• Example: Displaying only active users in a reference field for the User table.
• How to Use: In the reference field’s dictionary entry, go to the “Reference Qualifier” section and select “Simple”. Then, enter your query, like active=true.

2. Dynamic Reference Qualifier

• Description: Uses a dynamically generated query based on context, often referencing values from other fields on the current form. This makes the filtering more adaptable.
• Example: Displaying only servers that belong to the same business service as the incident.
• How to Use:
1. Create a Dynamic Filter Option (System Definition > Dynamic Filter Options). Define the conditions for your filter.
2. In the reference field’s dictionary entry, select “Dynamic” for the Reference Qualifier and choose the Dynamic Filter Option you created.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

• Description: This is the most powerful type, allowing you to write custom JavaScript code to define complex, context-aware queries. It can handle logic that the other two types cannot.
• Example: Filtering the Incident table to show only incidents assigned to the current user’s assignment group AND have a priority less than 3 (High or Critical).
• How to Use:
1. In the reference field’s dictionary entry, select “Advanced” for the Reference Qualifier.
2. Enter your JavaScript code in the adjacent text area. The code should return a query string.

        // Example for Advanced Reference Qualifier:
        // Assuming 'caller_id' is a field on the current form, and we want to show CIs related to that caller's department.
        javascript: 'sys_idIN' + new UserUtil().getDepartmentCIs(current.caller_id);
        // Or a simpler example directly in the field:
        javascript: 'assignment_group=' + gs.getUser().getMyGroups()[0] + '^priority<3';
        // Note: The second example is simplistic and might not cover all group scenarios.
        // A more robust example would be:
        // javascript: 'assignment_group=' + current.assignment_group + '^priority<3'; // If assignment_group is on the form
        

Difference Between Types:

• Simple vs. Dynamic: Simple is static. Dynamic adapts based on form field values using pre-defined options.
• Dynamic vs. Advanced: Dynamic uses pre-configured options. Advanced allows custom JavaScript logic for maximum flexibility.
• Simple vs. Advanced: Simple is a basic query string. Advanced offers full scripting power.

By mastering these ten scenarios and the underlying concepts like reference qualifiers, you'll be well-equipped to leverage the full power of the ServiceNow CMDB and its associated modules. These practical applications are not just theoretical; they are the building blocks for robust and efficient IT service management within your organization. Keep exploring, keep scripting, and keep building!