Streamline Child Incident Closure with Automation

By /






Automating Child Incident Closure: A Practical Guide for IT Service Management


Automating Child Incident Closure: Streamlining IT Support with Smart Workflows

In the dynamic world of Information Technology Service Management (ITSM), efficiency is paramount. When dealing with recurring issues or widespread problems, the ability to manage and resolve incidents effectively can significantly impact user productivity and overall system stability. One common scenario in ITSM is the concept of a problem, which is defined as the underlying cause of one or more incidents. When a single problem affects multiple users simultaneously, it often leads to the creation of a parent incident, with each individual user’s issue being logged as a child incident.

The challenge arises in ensuring that when the overarching parent incident is resolved and closed, all its associated child incidents are also automatically closed. Manually tracking and closing each child incident can be a tedious, error-prone, and time-consuming process, diverting valuable resources from more critical tasks. This is where automation steps in, offering a robust solution to streamline this workflow and enhance the efficiency of your IT support operations.

This article delves into the intricacies of automating child incident closure, exploring the underlying concepts, practical implementation strategies, and the benefits it brings to your ITSM framework. We’ll leverage insights from common ITSM practices and provide concrete examples to illustrate how this automation can be achieved, often within popular ITSM platforms like ServiceNow.

Understanding the Problem-Incident Relationship

Before we dive into the automation, it’s crucial to grasp the fundamental relationships between incidents, problems, and change requests. This understanding forms the bedrock of effective ITSM.

What is a Problem?

As per the definition, a problem in ITSM refers to the underlying cause of one or more incidents. It’s not just a single occurrence of an issue; it’s the root cause that, if left unaddressed, will continue to spawn more incidents. Think of it like a leaky pipe: the leak is the incident, but the cracked pipe is the problem.

Identifying and resolving problems is a proactive approach to IT support. Instead of just fixing the symptoms (individual incidents), we aim to eliminate the root cause, thereby preventing future occurrences.

What is an Incident?

An incident, on the other hand, is an unplanned interruption to an IT service or a reduction in the quality of an IT service. When an end-user experiences an issue – their application crashes, they can’t log in, or their printer isn’t working – that’s an incident.

When the same issue is repeatedly happening to the same employee, it might suggest a more persistent underlying problem. However, if the same problem is happening to multiple people at the same time, it indicates a widespread issue. In such scenarios, IT support often establishes a single parent incident to represent the overall problem. Then, each affected individual’s specific instance of the issue is logged as a child incident, linked back to the parent.

The Role of Change Requests

The relationship doesn’t end with problems and incidents. Sometimes, resolving a problem or addressing the root cause of multiple incidents requires making changes to the IT environment. This is where change requests come into play. A change request is a formal proposal for an alteration to some part of the IT infrastructure.

The typical flow might look like this: An incident is reported. If it’s a recurring or widespread issue, it’s escalated to a problem record to investigate the root cause. Once the root cause is identified, a change request might be created to implement a fix, such as patching software or reconfiguring a server. Upon successful implementation of the change, the problem is resolved, and all associated incidents (both parent and child) can then be closed.

Automating Child Incident Closure: The Core Logic

The primary goal here is to ensure that closing a parent incident automatically triggers the closure of all its associated child incidents. This significantly reduces manual effort and minimizes the chance of lingering open child tickets, which can skew reporting and create a false impression of ongoing issues.

Logic for Parent Incident Closure

The most common and effective way to achieve this automation is by implementing an after business rule. This type of rule executes after a record is updated in the system, allowing it to react to the changes made.

Here’s the logic, often translated into scripting within an ITSM platform:


    // Business Rule Configuration:
    // Table: Incident
    // When: after
    // Update: true
    // Condition: current.state.changesTo(7); // Assuming '7' is the sys_id or value for the 'Closed' state

    // Script:
    if (current.state == 7 && current.parent == '') { // Check if state is Closed and it's NOT a child incident itself
        // GlideRecord to find child incidents
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id); // Find incidents where the 'parent' field points to the current incident's sys_id
        grChild.query(); // Execute the query

        while (grChild.next()) { // Loop through each found child incident
            grChild.state = 7; // Set the state to Closed (matching the parent's state)
            grChild.update(); // Update the child incident record
        }
    }

Explanation of the Script:

  • current.state.changesTo(7);: This is a condition that triggers the business rule only when the ‘state’ field of the current incident record is changed to the value ‘7’. You’ll need to verify what value ‘7’ represents for the ‘State’ field in your specific ITSM platform. Commonly, ‘7’ might represent ‘Closed’ or a similar final state.
  • if (current.state == 7 && current.parent == '') { ... }: This code block ensures that the logic only runs when two conditions are met:
    • The incident’s state is indeed ‘Closed’ (value 7).
    • The parent field is empty (''). This is a critical check to identify actual parent incidents, preventing a child incident from incorrectly trying to close other incidents if it were somehow marked as a parent.
  • var grChild = new GlideRecord('incident');: This line initiates a query to the ‘incident’ table. In ServiceNow, GlideRecord is the API used to interact with database tables.
  • grChild.addQuery('parent', current.sys_id);: This is the core of finding child incidents. It adds a query condition to find all records in the ‘incident’ table where the ‘parent’ field matches the unique system ID (sys_id) of the current incident (the one that just got closed).
  • grChild.query();: This executes the search for child incidents based on the defined query.
  • while (grChild.next()) { ... }: This loop iterates through each incident record returned by the query. For every child incident found:
    • grChild.state = 7;: The ‘state’ field of the child incident is set to ‘Closed’ (value 7).
    • grChild.update();: The changes made to the child incident are saved to the database.

Interview Relevance:

When asked about automating related record closures, this scenario is a classic example. Being able to explain the use of after business rules, GlideRecord, query conditions, and the importance of checking the parent/child relationship demonstrates a solid understanding of ITSM automation principles.

Preventing Premature Incident Closure: Enforcing Task Completion

A critical aspect of incident management is ensuring that all associated work is completed before an incident is formally closed. This applies not only to individual incidents but also to problems and change requests, which often have associated tasks.

The Requirement: No Open Tasks, No Closure

The requirement is straightforward: an employee should not be able to close an incident (or a problem or change request) if there are any open tasks associated with it. This prevents situations where an incident is marked as resolved, but the actual remediation work or required actions are still pending.

Implementation: A Before Business Rule

To enforce this rule, a before business rule is typically used. A ‘before’ business rule runs before a record is saved, allowing you to validate data and, if necessary, prevent the save operation and provide feedback to the user.

Here’s the logic for enforcing task completion before incident closure:


    // Business Rule Configuration:
    // Table: Incident
    // When: before
    // Insert: false
    // Update: true
    // Condition: current.state.changesTo(3); // Assuming '3' is the state value for 'Closed'

    // Script:
    if (current.state == 3) { // Check if the intended state is 'Closed'
        // GlideRecord to find open incident tasks associated with this incident
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id); // Link to the current incident
        grTask.addQuery('state', '!=', 3); // Assuming '3' is the state value for 'Closed' (Adjust this value based on your platform's 'Closed' state for incident tasks)
        grTask.query();

        if (grTask.hasNext()) { // If there are any open tasks found
            gs.addErrorMessage('Cannot close the incident because there are open tasks.'); // Display an error message to the user
            current.setAbortAction(true); // Prevent the incident from being saved (closed)
        }
    }

Explanation of the Script:

  • current.state.changesTo(3);: This condition triggers the rule when the incident’s state is being changed to ‘Closed’ (assuming ‘3’ is the state value for ‘Closed’).
  • if (current.state == 3) { ... }: This block executes if the incident is being set to the ‘Closed’ state.
  • var grTask = new GlideRecord('incident_task');: This initializes a query to the ‘incident_task’ table.
  • grTask.addQuery('incident', current.sys_id);: This links the search to the current incident, finding only tasks specifically assigned to it.
  • grTask.addQuery('state', '!=', 3);: This is crucial. It looks for tasks where the state is *not* ‘Closed’. You’ll need to confirm the correct state value for ‘Closed’ in your ‘incident_task’ table.
  • if (grTask.hasNext()) { ... }: This checks if the query returned any results (i.e., if there are any open incident tasks).
  • gs.addErrorMessage('Cannot close the incident because there are open tasks.');: If open tasks exist, this user-friendly message is displayed to the person attempting to close the incident.
  • current.setAbortAction(true);: This is the key command that prevents the incident from being saved in its current state. The closure operation is aborted.

Extending to Problems and Change Requests:

The same principle applies to problems and change requests. These are also often derived from the task table, or they have their own dedicated task tables (e.g., problem_task, change_task). You would implement similar before business rules on the respective tables, querying for open tasks associated with the problem or change request before allowing them to be closed.

Troubleshooting:

  • Incorrect State Values: The most common issue is using the wrong numerical or textual values for the ‘Closed’ state in your business rules. Always double-check the exact values defined in your ITSM platform’s dictionary for the ‘State’ field on the relevant tables (incident, incident_task, problem, problem_task, etc.).
  • Scope of the Rule: Ensure the business rule is correctly scoped to run only on updates and when the state change is to ‘Closed’. An improperly scoped rule might trigger at the wrong time or miss the intended scenario.
  • Task Table Mismatches: Verify that the script is querying the correct task table and correctly linking tasks to the parent record (incident, problem, change).

Automating Incident Closure from Problem Resolution

When a problem record is resolved, it signifies that the root cause of recurring incidents has been identified and addressed. In such cases, all associated incidents should ideally also be closed.

The Requirement: Closing Incidents When a Problem is Closed

When a problem record is set to a resolved or closed state, any incidents that were linked to this problem should also be automatically moved to a closed state.

Implementation: An After Business Rule on the Problem Table

This automation is best achieved with an after business rule on the Problem table.


    // Business Rule Configuration:
    // Table: Problem
    // When: after
    // Update: true
    // Condition: current.state.changesTo(7); // Assuming '7' is the state value for 'Closed' on the Problem table

    // Script:
    if (current.state == 7) { // Check if the problem is being closed
        // GlideRecord to find incidents associated with this problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Link to the current problem's sys_id
        grIncident.addQuery('state', '!=', 7); // Assuming '7' is the state value for 'Closed' on the Incident table
        grIncident.query();

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

Explanation of the Script:

  • current.state.changesTo(7);: Triggers the rule when the problem’s state changes to ‘Closed’ (assuming ‘7’ for closed problems).
  • if (current.state == 7) { ... }: Executes the logic if the problem is indeed being closed.
  • var grIncident = new GlideRecord('incident');: Initializes a query to the ‘incident’ table.
  • grIncident.addQuery('problem_id', current.sys_id);: This links incidents to the current problem record using the ‘problem_id’ field.
  • grIncident.addQuery('state', '!=', 7);: This ensures we only attempt to close incidents that are not already closed. You’ll need to confirm the ‘Closed’ state value for incidents.
  • The script then iterates through these incidents, sets their state to ‘Closed’, and updates them.

Troubleshooting:

  • Problem-Incident Linking: Ensure that incidents are correctly linked to problems using the ‘problem_id’ field. If a different field is used, the query will need adjustment.
  • State Value Consistency: Pay close attention to the ‘Closed’ state values for both the Problem and Incident tables. Inconsistencies here will prevent the automation from working.

The Broader ITSM Ecosystem: Task Tables and Relationships

Understanding the relationships between different ITSM tables is crucial for effective automation. Many ITSM functionalities are built upon a common foundation.

Understanding the Task Table Hierarchy

In many ITSM platforms, tables like incident, problem, and change request are not standalone entities but rather extensions of a base task table. This inheritance allows them to share common fields and functionalities, making it easier to manage related records and implement consistent workflows.

Examples of Task-Derived Tables:

  • incident: Manages unplanned interruptions to IT services.
  • problem: Investigates and resolves the root cause of recurring incidents.
  • change request: Manages planned alterations to the IT infrastructure.
  • change_task: Tasks associated with implementing a change request.
  • problem_task: Tasks associated with investigating a problem.
  • incident_task: Tasks associated with resolving an incident.
  • Other common task-based tables might include request, request_item, sc_task (Service Catalog Task), etc.

The fact that these tables extend from a common base means that concepts like states, assignments, and due dates often behave similarly across different task types, simplifying the creation of robust ITSM processes.

Benefits of Automating Child Incident Closure

Implementing these automation strategies offers a multitude of benefits:

  • Increased Efficiency: Frees up IT support staff from tedious manual tasks, allowing them to focus on higher-value activities like problem resolution and proactive service improvement.
  • Reduced Errors: Eliminates the possibility of human error in tracking and closing multiple related tickets.
  • Improved Data Accuracy: Ensures that incident data is up-to-date and reflects the true status of resolutions, leading to more reliable reporting and analytics.
  • Faster Resolution Times: By automatically closing child incidents when the parent is resolved, the perceived and actual resolution time for the overall issue is reduced.
  • Enhanced User Satisfaction: Users experience a more streamlined and efficient support process, leading to higher satisfaction levels.
  • Better Resource Management: Allows IT managers to allocate resources more effectively by having a clear and accurate view of ongoing and resolved issues.

Conclusion

Automating child incident closure, enforcing task completion before closure, and linking incident resolution to problem closure are not just technical implementations; they are fundamental pillars of an efficient and mature IT Service Management practice. By leveraging the power of business rules and scripting within your ITSM platform, you can transform complex, manual workflows into seamless, automated processes.

The ability to effectively manage the lifecycle of incidents, problems, and change requests is a testament to an organization’s commitment to operational excellence. By implementing the strategies discussed in this article, you can significantly enhance your IT support team’s productivity, improve data integrity, and ultimately deliver a superior service experience to your users.

Remember, the key lies in understanding the relationships between different ITSM records and employing the right automation tools – often business rules – to enforce desired workflows. This not only streamlines daily operations but also builds a more resilient and responsive IT environment.


Scroll to Top