Understanding Parent-Child Incidents in ITSM

By /






The Symphony of Support: Understanding Parent and Child Incidents in ITSM


The Symphony of Support: Understanding Parent and Child Incidents in ITSM

Let’s face it: in the bustling world of IT, things don’t always go according to plan. Servers hiccup, applications crash, and sometimes, the entire network decides to take an unscheduled coffee break. When these digital disruptions occur, they don’t often happen in isolation. One major issue can ripple through an organization, affecting dozens, hundreds, or even thousands of users simultaneously.

Imagine the chaos if every single affected user logged their own individual ticket for the same underlying problem. Your service desk would be swamped, communication would break down, and getting a clear picture of the true impact would be like trying to herd cats in a hurricane. This is precisely where the elegant solution of Parent and Child Incidents steps onto the stage, transforming potential pandemonium into a coordinated, efficient response. It’s a cornerstone of effective IT Service Management (ITSM), ensuring that your support team can tackle widespread issues with clarity and control.

First, The Basics: What’s an Incident, Really?

Before we dive into the family dynamics of incidents, let’s nail down what an incident truly is. Think of it like this: you’re working diligently on your computer, suddenly your email client freezes, or your printer refuses to print your critical report. That sudden, unexpected interruption to a service you rely on – that’s an incident.

As per our foundational understanding (Reference 19): “A sudden interruption in the service when the employee works in the organization. If something suddenly stopped working, they will get the support from a support engineer by creating an incident.”

It’s about getting things back to normal, fast. An incident isn’t about finding a permanent fix; it’s about restoring service as quickly as possible. When you report that your email isn’t working, the support engineer’s first priority is to get you back to sending emails, not necessarily to debug the deep-seated software glitch that caused the freeze. That’s a job for someone else, or rather, another type of record entirely.

Beyond the Incident: The Curious Case of the Problem Record

Now, what if that email client keeps freezing every Tuesday morning? Or what if your printer works for a day, then goes rogue again? When the same issue starts playing a recurring role, it signals something deeper than a one-off glitch. This is where a Problem Record comes into play.

Referencing our definitions (Reference 20 & 21): “If the same issue is repeatedly happening to the same employee, then it is called a problem… If the issue is repeatedly occurring, then we will create a problem from incident.”

A problem is the underlying cause of one or more incidents. While an incident focuses on the immediate restoration of service, a problem aims to identify the root cause, develop a workaround, and ultimately implement a permanent solution to prevent future recurrence. It’s about getting to the “why” rather than just fixing the “what.”

Creating a Problem from an Incident: A Proactive Step

This linkage is crucial for proactive IT management. Imagine a scenario where a specific application bug causes several users to experience crashes daily. Each crash generates an incident. But instead of just resolving each incident individually (perhaps by restarting the application for the user), a savvy support engineer recognizes the pattern.

They can then elevate one of these recurring incidents into a problem record. This move signifies a shift in focus: from firefighting to strategic resolution. The problem record then becomes the central point for investigation, diagnosis, and eventually, a long-term fix. It ensures that valuable time isn’t spent repeatedly fixing symptoms when a cure is needed.

The Grand Orchestration: Parent and Child Incidents Unveiled

Now, let’s get to the heart of our discussion: Parent and Child Incidents. This powerful concept emerges when a single underlying issue affects not just one person repeatedly, but multiple people simultaneously. It’s the difference between your email freezing (one incident, possibly leading to a problem) and the entire email server going down for the whole company.

Our reference makes it clear (Reference 20): “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.”

Think of it as the IT equivalent of a natural disaster. When a hurricane hits, emergency services don’t open a separate case for every single person affected; they declare a major incident (the “parent”) and then manage all individual requests for help (the “children”) under that umbrella. Similarly, in IT, if the company’s main network switch fails, dozens or hundreds of users will suddenly lose connectivity. Each user might call the help desk and report “my internet isn’t working.”

Instead of treating these as 100 separate, unrelated incidents, the service desk identifies the commonality. They then designate one overarching incident as the “parent” incident, linking all other user-reported incidents (the “children”) to it. This parent incident becomes the single source of truth for the major outage, while the child incidents represent the individual impact on users.

Real-World Scenario: The Office Printer Meltdown
Imagine an office floor where the shared printer suddenly stops working. Five different employees, unaware of each other’s attempts, try to print and find it’s unresponsive. Each calls the help desk. Without parent/child incidents, you’d have five separate tickets, each needing individual attention and updates. With parent/child, the first incident becomes the parent, and the subsequent four are linked as children. All communication and resolution efforts focus on the parent.

Benefits of the Parent-Child Incident Model

The advantages of adopting this model are significant:

  • Streamlined Communication: Instead of updating 50 individual users, the support team focuses on updating the parent incident. Any status changes, workarounds, or resolution notes on the parent automatically apply or can be easily propagated to all child incidents. This saves an enormous amount of time and ensures everyone receives consistent information.
  • Reduced Workload for Support Agents: Agents aren’t bogged down by duplicate efforts. They resolve the core issue once on the parent incident, knowing that all linked child incidents will benefit from that single action.
  • Accurate Reporting & Impact Assessment: By consolidating widespread issues under a single parent, IT management gets a much clearer and more accurate picture of the true impact and scope of an outage. This data is invaluable for trend analysis, resource allocation, and future improvements.
  • Faster Resolution: Resources can be concentrated on the root cause represented by the parent, leading to quicker identification and resolution of the widespread problem.
  • Improved Customer Experience: Users are informed promptly and consistently, even if they’ve submitted an individual ticket. They see that their issue is acknowledged and being handled as part of a larger effort, reducing frustration.

When to Use Parent-Child Incidents? Real-World Scenarios

This model is ideal for:

  • Network Outages: A router failure impacting an entire building or campus.
  • Application Downtime: A critical business application like CRM or ERP becomes unavailable for many users.
  • Email Server Problems: Widespread inability to send or receive emails.
  • System Performance Degradation: A server or database is overloaded, causing slowdowns for a large user base.
  • Widespread Software Bugs: A newly deployed software update introduces a bug affecting many users’ daily tasks.

The Magic Behind the Scenes: How Parent-Child Incidents Work Their Charm

The real beauty of the parent-child relationship lies in its inherent automation. As our reference states, “whenever you close the parent incident the child incidents will be also get closed.” This isn’t magic; it’s smart workflow design, often implemented through business rules or similar automation scripts within an ITSM platform like ServiceNow.

The Technical Heartbeat: Scripting Parent-Child Automation

Let’s look at how this automatic closure is typically achieved. In platforms like ServiceNow, this functionality is usually implemented using a “Business Rule.” A Business Rule is a server-side script that runs when a record is displayed, inserted, updated, or deleted. For parent-child incident closure, an “After Update” Business Rule is perfect.

Here’s the logic from our reference (Reference 26):


When -- After
Update - true

Condition: current.state.changesTo(7);

if (current.state == 7 && current.parent == '') {

        // 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
        }
    }

Dissecting the Script:

  • When — After, Update – true: This means the script runs after an incident record has been successfully updated in the database.
  • Condition: current.state.changesTo(7);: This is a crucial performance optimization. The script only fires if the ‘state’ field of the current incident (the one being updated) has just changed to ‘7’. In many ITSM systems, ‘7’ represents the ‘Closed’ state. This prevents the script from running unnecessarily every time any field on an incident is updated.
  • if (current.state == 7 && current.parent == ''): This is the core logical gate.
    • current.state == 7: Checks if the current incident’s state is indeed ‘Closed’.
    • current.parent == '': This is key! It ensures that the script only proceeds if the current incident is itself a parent incident (i.e., it doesn’t have a parent incident linked to it). We don’t want a child incident accidentally trying to close its siblings or other unrelated incidents.
  • var grChild = new GlideRecord('incident');: This line initializes a new GlideRecord object, specifically targeting the ‘incident’ table. GlideRecord is a powerful API in ServiceNow used to perform database operations.
  • grChild.addQuery('parent', current.sys_id);: This adds a filter to our query. We’re looking for incident records where their ‘parent’ field matches the sys_id (unique identifier) of the current parent incident that just closed.
  • grChild.query();: Executes the query against the database to fetch all matching child incidents.
  • while (grChild.next()) { ... }: This loop iterates through each child incident found by the query.
  • grChild.state = 7;: Inside the loop, for each child incident, its ‘state’ field is set to ‘7’ (Closed).
  • grChild.update();: This command saves the changes to the child incident record in the database, effectively closing it.

This script elegantly automates a repetitive and error-prone manual task, ensuring consistency and efficiency in incident resolution.

Expanding the Horizon: Incident, Problem, and Change – A Connected Universe

The parent-child incident relationship doesn’t exist in a vacuum. It’s an integral part of a broader IT Service Management framework, often encompassing Problem Management and Change Management. These three pillars – Incident, Problem, and Change – are deeply intertwined, working together to deliver reliable IT services.

As summarized in our references (Reference 29 & 32): “If a person faces 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… incident, problem, change request which are extending task table.”

This highlights a crucial architectural point: in many ITSM platforms, Incident, Problem, and Change records are all derived from a common ‘Task’ table. This ‘Task’ table provides foundational fields and functionalities, allowing for consistent processes and reporting across these different record types.

The Incident-Problem-Change Lifecycle in Action

Let’s walk through a comprehensive scenario:

  1. Incident Creation: Users report slow application performance. Multiple users complain. A parent incident is created for the widespread slowdown, and individual user tickets become child incidents.
  2. Problem Identification: After initial investigation, support engineers notice a pattern. The application slowness seems to correlate with peak usage times, suggesting a potential database bottleneck. Recognizing this recurring pattern and its widespread impact (via the parent incident), they create a Problem Record directly from the parent incident.
  3. Problem Resolution: The problem management team delves deeper. They diagnose that the database server lacks sufficient RAM to handle the load during peak hours. They identify a need for a hardware upgrade.
  4. Change Request: To implement the hardware upgrade (a significant alteration to the IT infrastructure), a Change Request is initiated from the problem record. This ensures proper planning, approval, risk assessment, and scheduling for the change.
  5. Change Implementation & Closure: The change is approved, scheduled, and successfully implemented during a maintenance window.
  6. Problem Closure: Once the change is verified to have resolved the database bottleneck, the Problem Record is closed. Crucially, the system can be configured to automatically close all associated incidents.
  7. Incident Closure: With the problem resolved, the parent incident is closed. This action, thanks to our Business Rule, automatically closes all the child incidents, providing a holistic and documented resolution for everyone involved.

Closing Incidents from Problems: Another Automation Gem

Just as closing a parent incident can close its children, closing a problem can also trigger the closure of all associated incidents. This makes perfect sense: if the root cause is fixed, the symptoms (incidents) should naturally cease.

Here’s the automation script (Reference 28):


if (current.state == 7) {

        // GlideRecord to find incidents associated with the problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id);
        grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed'
        grIncident.query();

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

This script, likely an “After Update” Business Rule on the Problem table, checks if the current problem has been closed (`current.state == 7`). If so, it finds all incidents linked to this problem (`grIncident.addQuery(‘problem_id’, current.sys_id)`) that are not yet closed (`grIncident.addQuery(‘state’, ‘!=’, 7)`) and then proceeds to close them, neatly tidying up all related records.

Preventing Premature Closures: Incident Tasks and Their Guardians

Sometimes, an incident itself might have sub-tasks that need to be completed before it can truly be considered resolved. Closing an incident while crucial tasks are still open can lead to incomplete resolutions and user dissatisfaction. Smart ITSM platforms allow for safeguards against this.

Consider this logic (Reference 27):


var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', 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 incident because there are open tasks.');
        current.setAbortAction(true);
    }

This script, often a “Before Update” Business Rule on the Incident table when its state changes to ‘Closed’, prevents the incident from being closed if any associated ‘incident_task’ records are still open. If open tasks are found (`grTask.hasNext()` is true), an error message is displayed (`gs.addErrorMessage`), and the attempted closure of the incident is stopped (`current.setAbortAction(true)`). This ensures a thorough and complete resolution process, protecting against overlooked steps.

Navigating Relationships: One-to-Many, Many-to-Many in ServiceNow

Understanding how records relate to each other is fundamental in any database-driven system, especially in ITSM. Parent and child incidents exemplify a particular type of relationship.

Our reference clarifies common relationships (Reference 40): “One-to-Many Relationship: Users and Incidents, where one user can have multiple incidents, but each incident is assigned to one user. Many-to-Many Relationship: Incidents and Groups, where an incident can be associated with multiple groups, and a group can be associated with multiple incidents.”

One-to-Many in Incident Management

The relationship between a Parent Incident and its Child Incidents is a classic One-to-Many. One parent incident can have multiple child incidents linked to it, but each child incident can only have one parent. Similarly, one user can submit many incidents over time, but generally, an incident is opened by, or on behalf of, a single user (the caller).

Many-to-Many in Incident Management

While not directly tied to the parent-child structure, many-to-many relationships are also common. For instance, an incident might require the involvement of multiple IT groups (e.g., Network Team, Server Team, Application Support). Conversely, a single IT group might be involved in resolving numerous incidents simultaneously. This complexity is managed through related lists and junction tables in the database, allowing for flexible collaboration.

Troubleshooting Common Parent-Child Incident Scenarios

Even with robust automation, issues can arise. Here’s a look at some common troubleshooting scenarios related to parent-child incidents:

Child Incidents Not Closing Automatically

  • Check Business Rule Condition: Is the state value correct? Does ‘7’ truly mean ‘Closed’ in your system, or has it been customized? Is the condition `current.state.changesTo(7)` actually triggering?
  • Verify Business Rule Scope: Is the Business Rule set to run ‘After’ an ‘Update’? Is it active?
  • Parent Field Check: Does the parent incident genuinely have `current.parent == ”`? Sometimes, a parent incident might accidentally be linked to another “super-parent,” which would prevent this specific rule from firing.
  • Script Errors: Check system logs for any JavaScript errors within the Business Rule script. Typos or incorrect object references can break the automation.
  • Permissions: Does the user account under which the Business Rule runs have the necessary permissions to update child incidents?

Incorrectly Linked Parent/Child Incidents

  • Manual Correction: Sometimes, a child incident is mistakenly linked to the wrong parent, or an incident that should be a child is created standalone. These usually require manual intervention by a support agent to re-link or unlink.
  • Process Review: If this happens frequently, review the process for identifying and linking parent-child incidents. Is the training sufficient? Are there clear guidelines for agents?
  • UI Customizations: If custom UI actions are used for linking, ensure they are working correctly and not allowing misconfigurations.

Performance Issues with Large Numbers of Child Incidents

  • Database Indexing: For very large installations with thousands of child incidents, ensure that the `parent` field on the incident table is properly indexed for fast query performance.
  • Script Optimization: While the provided script is efficient, ensure no other, less optimized scripts are running concurrently that could slow down the process.
  • Asynchronous Processing: For extremely high volumes, consider making the child incident closure an asynchronous operation (e.g., using a background job) to avoid impacting the user experience when closing the parent.

Interview Spotlight: Mastering Parent and Child Incident Concepts

For anyone aspiring to work in IT Service Management, particularly in roles involving platforms like ServiceNow, a solid understanding of parent and child incidents is non-negotiable. This topic frequently appears in interviews because it demonstrates practical knowledge of ITSM principles, automation, and system functionality. Interviewers want to see that you understand not just *what* it is, but *why* it’s important and *how* it works.

Key Questions You Might Encounter:

  • “Explain the concept of parent and child incidents. When would you use them?”
  • “What is the relationship between an incident and a problem? Can you create one from the other?”
  • “How would you ensure that when a parent incident is closed, all its child incidents also close automatically?” (This is your cue to discuss Business Rules and the script.)
  • “Describe a real-world scenario where parent-child incidents would significantly improve IT support.”
  • “What are the benefits of using parent-child incidents from both a service desk and end-user perspective?”
  • “How does an incident relate to a change request, and when would you create a change from an incident?”
  • “Can you prevent an incident from closing if it has open tasks? How?” (Another Business Rule scenario.)

How to Ace Your Answers:

  • Go Beyond Definitions: Don’t just regurgitate definitions. Explain the “why” and “how.”
  • Provide Examples: Use clear, concise real-world examples to illustrate your points.
  • Discuss Automation: Showcase your understanding of how these concepts are implemented technically (e.g., Business Rules, GlideRecord).
  • Connect to ITIL: Frame your answers within the context of ITIL best practices for service management.
  • Emphasize Benefits: Always highlight how these processes lead to better efficiency, user satisfaction, and data quality.

Beyond the Code: Creating Records with Scripts

While our focus has been on the dynamic relationship between incidents, it’s worth noting the foundational capability of scripting record creation. The ability to programmatically create Incident, Problem, or Change records (as seen in References 23, 24, 25) using `GlideRecord` is essential for integrations, data imports, or custom workflows. It demonstrates the platform’s flexibility and the power developers have to extend its core functionalities. These scripts typically involve initializing a new record, setting its field values, and then calling `insert()` to save it to the database.

Conclusion: The Power of Structured Support

In the complex landscape of IT service delivery, managing disruptions effectively is paramount. Parent and Child Incidents offer a powerful, elegant, and efficient way to handle widespread issues, transforming potential chaos into structured, coordinated problem-solving.

By centralizing communication, reducing redundant effort, and providing clear insights into the true impact of outages, this model empowers IT teams to restore services faster, communicate more effectively, and ultimately deliver a superior support experience. It’s a testament to how intelligent design and automation, combined with a deep understanding of ITSM principles, can make a profound difference in the daily operations of any organization. So, the next time your network decides to take a vacation, remember the symphony of support that parent and child incidents conduct, bringing harmony back to your IT environment.


Scroll to Top