Auto Closing Related Incidents: Streamlining Your IT Service Management with Intelligent Automation

In the dynamic world of IT Service Management (ITSM), efficiency is paramount. When recurring issues plague your organization, managing them effectively can become a significant challenge. This is where the concepts of “Problem Management” and the intelligent automation of “Auto Closing Related Incidents” come into play. Imagine a scenario where a single, underlying cause creates a cascade of individual user issues. Without a robust system, closing each of these individual issues one by one is not only time-consuming but also prone to errors and missed opportunities for root cause analysis. This article will delve deep into how to effectively leverage ITSM capabilities to automatically close related incidents when a parent incident or problem is resolved, thereby enhancing operational efficiency and user satisfaction.

We’ll explore the fundamental differences between incidents and problems, understand the importance of linking them, and then dive into the technical implementation of automating the closure of child incidents. We’ll also touch upon related concepts like incident tasks and change requests, ensuring a comprehensive understanding of this powerful ITSM feature.

Understanding the Core Concepts: Incident vs. Problem

Before we get to the automation, it’s crucial to have a clear grasp of the basic building blocks: incidents and problems. This distinction is fundamental to effective ITSM.

What is an Incident?

An incident, in ITSM terms, is an unplanned interruption to an IT service or a reduction in the quality of an IT service. Essentially, it’s something that’s broken and needs immediate attention to restore normal service operation as quickly as possible. Think of it as a fire that needs to be put out – the priority is getting the service back up and running.

Example: A user can’t log in to their email. This is an incident because it’s an immediate interruption of service for that specific user. If multiple users report the same login issue simultaneously, it signals a larger, potentially underlying problem.

What is a Problem?

A problem, on the other hand, is the unknown underlying cause of one or more incidents. The goal of problem management is to identify the root cause of incidents and to prevent them from happening again. While incident management focuses on restoring service, problem management focuses on preventing future disruptions.

Example: If 20 employees report that they can’t log in to their email within a two-hour window, this isn’t just 20 separate incidents. It’s a strong indicator of a single underlying problem, such as a server outage, a network connectivity issue, or a faulty software update. In such cases, a “parent incident” might be created to represent the overall outage, and the individual user reports become “child incidents” linked to this parent. Once the root cause is fixed and the parent incident is closed, all associated child incidents should ideally be closed as well.

The reference material clearly articulates this distinction: “if the same issue is repeatedly happening to the same employee then it is called problem. if the same problem is happening to the multiple people at the same time then its an incident, where will create a parent incident and rest of all will be child incidents, whenever you close the parent incident the child incidents will be also get closed.” This highlights the crucial relationship and the hierarchical structure we can establish.

The Power of Linking: Problems and Incidents

The real magic happens when we establish a clear link between incidents and problems. This linkage allows us to manage recurring issues more effectively and automate resolutions.

Creating Problem Records from Incidents

It’s a common scenario where an initial incident is logged, and as more reports of the same or similar issues come in, the IT team realizes there’s a recurring pattern. At this point, it’s beneficial to escalate the investigation from incident management to problem management.

The reference states: “yes, if the issue is repeatedly occurring then we will create a problem from incident.” This is typically done by:

• Identifying a trend of similar incidents.
• Creating a new ‘Problem’ record.
• Linking the existing ‘Incident’ records to this new ‘Problem’ record.

This process ensures that the focus shifts from merely resolving individual disruptions to finding and fixing the fundamental cause. Once the problem is resolved (e.g., the server is back online, the software bug is patched), all the incidents linked to it can be addressed simultaneously.

Automating the Closure of Child Incidents

This is the core of our discussion – how to ensure that when a parent incident or a problem is resolved, all associated child incidents are automatically closed. This significantly reduces manual effort and ensures consistency.

Logic for Auto-Closing Child Incidents via Parent Incident

The most effective way to achieve this is by implementing an automated workflow, typically through a “Business Rule” in ITSM platforms like ServiceNow. A Business Rule is a piece of server-side JavaScript code that runs when a record is displayed, inserted, updated, or deleted.

The reference provides a specific logic: “Write a logic for whenever a parent incident is get closed all the child incidents should also get closed.?”

The answer involves an ‘after business rule’ that triggers when the parent incident’s state is updated to ‘Closed’.

    // Check if the current incident's state is 'Closed' AND it has a parent
    // (This condition ensures we're not processing already closed incidents or top-level issues that don't have children)
    if (current.state == 7 && current.parent != '') {
        // Get the parent incident's Sys ID
        var parentSysId = current.parent;

        // GlideRecord to find child incidents linked to this parent
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', parentSysId);
        // Optional: Add a query to ensure we only close open child incidents
        // grChild.addQuery('state', '!=', 7); // Assuming 7 is Closed
        grChild.query();

        while (grChild.next()) {
            // For each child incident found:
            // Set its state to 'Closed'
            grChild.state = 7; // Set the state to Closed

            // Update the child incident record
            grChild.update();

            // Optional: Log the action for auditing purposes
            gs.info("Child incident " + grChild.number + " automatically closed due to parent " + current.number + " being closed.");
        }
    }
    

Explanation of the Code:

• When -- After: This ensures the business rule runs after the parent incident’s state has been successfully updated to ‘Closed’.
• Update - true: The rule is designed to execute on updates.
• Condition: current.state.changesTo(7);: This is a crucial filter. It means the rule will only fire when the ‘state’ field is specifically changed *to* the value ‘7’ (assuming ‘7’ represents the ‘Closed’ state in your system). This prevents the rule from running every time an incident is updated, which would be inefficient.
• if (current.state == 7 && current.parent != ''): This checks if the current incident is indeed in the ‘Closed’ state (state == 7) AND if it has a parent field populated (current.parent != ”). This second part is vital; it targets incidents that are *children* of another incident. We don’t want to incorrectly close top-level incidents.
• var grChild = new GlideRecord('incident');: This initiates a query against the ‘incident’ table.
• grChild.addQuery('parent', current.sys_id);: This is the core of finding the children. It looks for all incident records where the ‘parent’ field matches the ‘sys_id’ of the current incident being closed.
• grChild.query();: Executes the query.
• while (grChild.next()) { ... }: This loop iterates through each child incident found.
• grChild.state = 7; // Set the state to Closed: For each child, its state is updated to ‘Closed’.
• grChild.update(); // Update the child incident: This saves the changes to the child incident record.

Handling Dependencies and Preventing Premature Closure

While automating closure is beneficial, it’s equally important to ensure that related tasks or sub-processes are completed before an incident, problem, or change request can be closed. This prevents incomplete work from being marked as resolved.

Ensuring Tasks are Closed Before Incident Closure

Consider an incident that requires multiple steps to resolve, often broken down into Incident Tasks. An incident task is a smaller, manageable piece of work derived from an incident. It’s crucial that these tasks are completed before the parent incident is considered closed.

The reference asks: “There is an incident and that incident has associated 2 tasks ,when u try to close that incident if any incident task is o pen so employee should not close the incident. Similarly for problem, and change request.?”

This requires a similar business rule, but this time, it prevents the closure if dependent tasks are open.

    // Check if the incident is attempting to move to the 'Closed' state
    if (current.state == 7) {
        // GlideRecord to find open incident tasks associated with this incident
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id);
        // Assuming '3' is the state value for 'Closed' for incident tasks. Adjust as necessary.
        grTask.addQuery('state', '!=', 3);
        grTask.query();

        // If any open incident tasks are found
        if (grTask.hasNext()) {
            // Display an error message to the user
            gs.addErrorMessage('Cannot close the incident because there are open incident tasks. Please close all associated tasks first.');
            // Abort the business rule and prevent the incident from being closed
            current.setAbortAction(true);
        }
    }
    

Explanation:

• When to run: before insert, update: This business rule runs before the incident is saved. This allows us to intercept the closure action.
• Condition: current.state.changesTo(7);: Similar to the previous rule, this triggers when the state is changing to ‘Closed’.
• if (current.state == 7): Checks if the target state is ‘Closed’.
• var grTask = new GlideRecord('incident_task');: Queries the ‘incident_task’ table.
• grTask.addQuery('incident', current.sys_id);: Links tasks to the current incident.
• grTask.addQuery('state', '!=', 3);: This is key – it finds tasks that are *not* in the ‘Closed’ state (assuming ‘3’ is ‘Closed’ for tasks).
• if (grTask.hasNext()): If even one open task exists.
• gs.addErrorMessage(...): A user-friendly message is displayed explaining why the closure is blocked.
• current.setAbortAction(true);: This is the crucial line that cancels the entire update operation, preventing the incident from being closed.

This same logic can be adapted for ‘Problem’ and ‘Change Request’ records by querying their respective task-related tables (e.g., problem_task, change_task) and applying similar checks.

Automating Incident Closure from Problem Resolution

When a problem is resolved, it often implies that all associated incidents stemming from that problem should also be considered resolved. This is a powerful way to clean up your incident backlog.

Logic for Closing Associated Incidents When a Problem is Closed

The reference explicitly asks: “Whenever problem is closed the associated incident will also get closed.?”

This requires another business rule, this time on the Problem table.

    // Check if the problem is being closed
    if (current.state == 7) {
        // GlideRecord to find incidents associated with this problem
        var grIncident = new GlideRecord('incident');
        // Assuming 'problem_id' is the field linking incident to problem
        grIncident.addQuery('problem_id', current.sys_id);
        // Optional: Only target incidents that are not already closed
        // Assuming 7 is the state value for 'Closed' on Incident
        grIncident.addQuery('state', '!=', 7);
        grIncident.query();

        while (grIncident.next()) {
            // For each associated incident:
            // Set its state to 'Closed'
            grIncident.state = 7; // Set the state to Closed

            // Update the incident record
            grIncident.update();

            // Optional: Log the action
            gs.info("Incident " + grIncident.number + " automatically closed due to Problem " + current.number + " being closed.");
        }
    }
    

Explanation:

• Table: Problem: The rule is placed on the Problem table.
• When to run: after update: Fires after a Problem record is updated.
• Condition: current.state.changesTo(7);: Triggers when the Problem’s state changes to ‘Closed’.
• if (current.state == 7): Confirms the Problem is indeed in the ‘Closed’ state.
• var grIncident = new GlideRecord('incident');: Initiates a query against the Incident table.
• grIncident.addQuery('problem_id', current.sys_id);: This is the crucial link. It searches for all incidents that have their ‘problem_id’ field populated with the ‘sys_id’ of the current Problem record being closed.
• grIncident.addQuery('state', '!=', 7);: This optional but recommended line ensures you only attempt to close incidents that are not already closed, preventing unnecessary updates.
• The rest of the loop works similarly to the child incident closure, updating the state of each found incident to ‘Closed’.

The Relationship Between Incident, Problem, and Change Management

Understanding these interconnected processes is key to a mature ITSM practice.

The reference summarizes this relationship: “if a person face some issue he will create an incident and if the same issue is happening again and again then he will create a problem, and if the support team feels like some changes are required in their software then they will create a change request.”

Let’s elaborate:

• Incident Management: Deals with immediate service disruptions. The focus is on quick restoration.
• Problem Management: Investigates recurring incidents to find root causes and implement permanent fixes to prevent future incidents. When a problem is resolved, it often triggers the closure of related incidents.
• Change Management: Manages modifications to the IT infrastructure or services. Often, resolving a problem requires a change (e.g., deploying a software patch, reconfiguring a server). So, a problem investigation might lead to the creation of a change request. Once the change is successfully implemented, it can then resolve the underlying problem, which in turn closes associated incidents.

This interconnectedness means that automating the closure of incidents based on problem or change resolution creates a seamless flow, ensuring that when the root cause is addressed, all its symptoms (incidents) are also cleared.

Conclusion: Embracing Intelligent Automation for IT Efficiency

The ability to automatically close related incidents is a cornerstone of effective, modern IT Service Management. By intelligently linking incidents to problems and leveraging automated workflows, organizations can significantly:

• Reduce Manual Effort: Freeing up valuable IT staff time from repetitive closure tasks.
• Improve Data Accuracy: Ensuring that related issues are handled consistently.
• Enhance User Satisfaction: Resolving issues faster and preventing recurring disruptions.
• Accelerate Root Cause Analysis: By automatically clearing the backlog of symptoms once the underlying problem is fixed.

Implementing these automated closures requires a solid understanding of your ITSM platform’s capabilities, particularly its scripting and business rule engines. By carefully configuring these rules, as outlined with the provided logic, you can transform your incident management process from a reactive firefighting operation into a proactive, efficient, and intelligent service delivery model. This not only benefits the IT team but ultimately provides a more stable and reliable IT experience for the entire organization.