Solution: The Parent-Child Incident Model

This is a classic example where the parent-child incident relationship in ServiceNow shines. The first reported incident of this nature should be treated as the parent incident. As more employees report the same issue, instead of creating new, independent incidents, they should be linked to this parent incident as child incidents.

Steps:

1. Identify and Create Parent Incident: The first support engineer to receive this report creates a high-priority incident, detailing the application, symptoms, and impacted users.
2. Link Child Incidents: For every subsequent report of the same issue, the support engineer looks up the existing parent incident and links the new report to it. In ServiceNow, this is typically done via the “Parent incident” field on the incident form.
3. Diagnosis and Resolution: The assigned support team focuses on diagnosing and resolving the root cause of the problem for the parent incident.
4. Mass Closure: Once the underlying issue is fixed and the parent incident is resolved, a business rule can automatically close all associated child incidents. This is achieved by a rule that triggers when the parent is closed, setting the state of all linked child incidents to ‘Closed’ as well.

ServiceNow Implementation:

Reference point 26) provides the logic for this:

// After Business Rule on Incident table
// When: After Update
// Condition: current.state.changesTo(7); // Assuming 7 is the state value for Closed

if (current.state == 7 && current.parent == '') { // Check if current incident is closed and it's a parent
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Filter by parent sys_id
    grChild.query();

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

This rule ensures that closing the parent automatically cascades the closure to all its children, saving significant administrative effort.

Solution: Elevating an Incident to a Problem Record

When an incident is reported repeatedly by the same user, or if the support team notices a pattern of similar incidents, it’s time to investigate the root cause. This is where the Problem Management module in ServiceNow comes into play. An incident can be escalated to a problem record to track the investigation into the underlying cause.

Steps:

1. Incident Creation: The user reports the slow performance as an incident.
2. Pattern Recognition: The support engineer notices this is a recurring issue for the user or observes similar incidents.
3. Create Problem Record: From the incident form, the support engineer can create a new problem record, automatically linking the incident to it. This “Problem” record will then be used to conduct a deeper investigation.
4. Root Cause Analysis (RCA): The problem management team (or the assigned engineer) will perform RCA, which might involve analyzing logs, system performance metrics, and user behavior.
5. Develop Workaround/Permanent Fix: Once the root cause is identified, a workaround might be implemented to provide immediate relief, followed by a permanent fix.
6. Link Incidents to Problem: All related incidents are linked to the problem record.
7. Remediation: The permanent fix might involve a change request.

ServiceNow Implementation:

Reference point 21) confirms: “yes, if the issue is repeatedly occurring then we will create a problem from incident.” ServiceNow provides a direct “Create Problem” related link or button on the incident form to facilitate this.

Solution: Incident-Driven Change Request for Emergency Fix

When an incident reveals a bug or an issue that requires a modification to the system, and that modification is needed urgently to restore service, a Change Request is initiated. In cases of application crashes, this often falls under an “Emergency Change.”

Steps:

1. Incident Creation: The application crash is reported as a high-priority incident.
2. Investigation: The support team quickly identifies that the issue is due to a bug in the application’s code or a faulty configuration.
3. Create Emergency Change: The support engineer, recognizing the need for a code fix or configuration update, creates an emergency change request directly from the incident.
4. Expedited Approval: Emergency changes typically bypass the standard change approval workflows or have a drastically shortened approval process, involving key stakeholders who can authorize the change quickly.
5. Implement Change: The development or operations team implements the fix (e.g., deploys a patch, rolls back a recent update, corrects configuration).
6. Incident Resolution: Once the change is implemented and verified, the application is restored, and the incident is resolved.

ServiceNow Implementation:

Reference point 22) states: “Yes, when ever you create an incident if the support engineer feels that their should be some change in the software then he will arise a change request from that incident.” ServiceNow makes this seamless. A related link or button on the incident form allows users to “Create Change Request.” You can select the type of change (e.g., Emergency) and populate relevant fields directly from the incident.

Solution: Automated Incident Creation via Scripting

For proactive communication or automated tracking of system events, ServiceNow scripting offers a powerful way to create incident records. This is particularly useful for mass notifications or for logging automated alerts.

Scenario Context: While you wouldn’t typically create “disruptive” incidents for planned maintenance (notifications or scheduled jobs are better for that), you might use scripting to create informational incidents for users about a specific alert, or to log a recurring system issue detected by monitoring tools.

ServiceNow Implementation:

Reference point 23) provides the exact script:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the user or caller
gr.category = 'inquiry'; // Example category
gr.subcategory = 'antivirus'; // Example subcategory
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the affected Configuration Item
gr.short_description = 'test record using script';
gr.description = 'test record using script' ;
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
gr.insert();
            

How to Adapt:

• Looping for Mass Creation: To create multiple incidents, you would wrap this code in a loop that iterates through a list of users, affected CIs, or specific conditions.
• Dynamic Data: The `caller_id`, `cmdb_ci`, `short_description`, and `description` would be dynamically populated based on the data source (e.g., user list, alert details).
• Use Case Example: Imagine a monitoring tool detects a performance threshold breach on a specific server. A script could automatically create an incident assigned to the infrastructure team, referencing the server (CMDB CI) and providing details about the breach.

Solution: Scripting for Problem and Change Automation

Automating the creation of Problem and Change Requests through scripting can significantly streamline IT operations, especially when dealing with alerts from monitoring tools or repetitive issues identified by analytics.

ServiceNow Implementation:

Reference points 24 and 25 provide the scripts:

// For Problem Record
var grProblem = new GlideRecord('problem');
grProblem.initialize();
grProblem.caller_id = '86826bf03710200044e0bfc8bcbe5d94';
grProblem.category = 'inquiry';
grProblem.subcategory = 'antivirus';
grProblem.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
grProblem.short_description = 'test record using script';
grProblem.description = 'test record using script';
grProblem.assignment_group = 'a715cd759f2002002920bde8132e7018';
grProblem.insert();

// For Change Request Record
var grChange = new GlideRecord('change_request');
grChange.initialize();
grChange.category = 'inquiry';
grChange.subcategory = 'antivirus';
grChange.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
grChange.short_description = 'test record using script';
grChange.description = 'test record using script';
grChange.assignment_group = 'a715cd759f2002002920bde8132e7018';
grChange.insert();
            

Use Case Example:

• Problem: A monitoring tool detects that a specific database server’s disk usage is consistently above 90% for three consecutive days. A scheduled job or an event script could trigger the creation of a ‘Problem’ record. This problem record would include details about the server, the threshold, and the duration. The `cmdb_ci` field would point to the database server CI.
• Change: Following the discovery of the problem (e.g., disk space is running out), an automated script could be triggered to request an increase in disk space. This would create an ‘Emergency Change Request’ if the situation is critical, or a ‘Normal Change Request’ if there’s a bit more time. The script would populate fields like `short_description` indicating the need for disk expansion and `cmdb_ci` for the server.

Solution: Enforcing Task Closure Before Incident Resolution

ServiceNow’s Incident Management is designed to ensure that all related work is completed before an incident is formally closed. This is achieved by using Business Rules to validate that all associated Incident Tasks are in a ‘Closed’ state.

ServiceNow Implementation:

Reference point 27) provides the script logic for this validation:

// Before Business Rule on Incident table
// When: Before Update
// Condition: current.state.changesTo(7); // Assuming 7 is the state value for Closed

var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id); // Find tasks related to the current incident
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
grTask.query();

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

Explanation:

• This ‘Before’ Business Rule runs just before an incident is updated, specifically when its state is about to change to ‘Closed’ (state value 7).
• It queries the `incident_task` table, looking for tasks linked to the current incident (`current.sys_id`).
• It filters out any tasks that are NOT closed (state != 3).
• If it finds even one open task (`grTask.hasNext()`), it displays an error message to the user and uses `current.setAbortAction(true)` to stop the incident from being closed.

Solution: Automated Incident Closure from Problem Resolution

Just as parent incidents can trigger the closure of child incidents, closing a problem record should ideally trigger the closure of all its associated incidents. This signifies that the recurring issue has been eradicated.

ServiceNow Implementation:

Reference point 28) provides the logic for this:

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

if (current.state == 7) { // If the problem is closed
    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Filter by the problem_id field
    grIncident.addQuery('state', '!=', 7); // Find incidents that are NOT already closed
    grIncident.query();

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

Explanation:

• This ‘After’ Business Rule runs after a Problem record is updated, specifically when its state changes to ‘Closed’ (state 7).
• It queries the `incident` table, looking for incidents where the `problem_id` field matches the `sys_id` of the currently closing problem.
• It further filters to only include incidents that are not already in a ‘Closed’ state.
• For each found incident, it sets the state to ‘Closed’ and updates the record.

Solution: Redirecting to Change Management or Enhancement Requests

When an issue isn’t a true incident (a disruption of expected service) but rather a suggestion for improvement, it shouldn’t be managed solely as an incident. It needs to be channeled into the appropriate process, which is often Change Management or a dedicated Request Fulfillment process for enhancements.

Steps:

1. Initial Incident Creation: The user typically logs this as an incident.
2. Investigation & Qualification: The support engineer investigates and determines that the system is behaving as designed, but the user desires a different functionality.
3. Closure as “Not an Incident” (or similar): The incident is closed with a resolution code like “Not a system issue,” “Functioning as designed,” or “Enhancement request.”
4. Re-routing/Guidance: The user is informed about the finding and guided on how to formally submit an enhancement request. This might involve:
   • Directing them to a specific portal for ‘Ideas’ or ‘Feature Requests’.
   • Creating a ‘Request’ item in ServiceNow’s Service Catalog for enhancement proposals.
   • Initiating a ‘Change Request’ if the enhancement is deemed valuable and requires formal evaluation and approval.
5. Formal Evaluation: The request then goes through the standard process for new features or improvements, which might involve business case development, prioritization, and then scheduling for implementation as a change.

Solution: Understanding Table Hierarchies

ServiceNow utilizes a powerful concept of table extensions, often referred to as inheritance. Many core ITSM modules, including Incidents, Problems, and Change Requests, extend from a common base table called `Task`. This allows for shared fields and functionalities across these different record types.

Explanation:

Reference point 32) lists them: `incident`, `problem`, `change_request` all extend from the `task` table. This means:

• Shared Fields: All records in these tables will have common fields inherited from the `task` table, such as:
  • Number
  • State
  • Assignment Group
  • Assigned To
  • Created / Updated On
  • Work Notes / Comments
  • Due Date
• Common Functionality: Features built on the `task` table, like task workflows, assignment rules, or SLA definitions, can often be applied to incidents, problems, and changes without needing to be recreated individually.
• Efficient Reporting: You can often write reports that query the `task` table to pull data across all these different record types simultaneously, filtering by `sys_class_name` to differentiate between Incidents, Problems, Changes, etc.

Solution: The Integrated ITSM Workflow

This scenario exemplifies the powerful integration between Incident, Problem, and Change Management within ServiceNow. It’s a common and highly effective workflow for addressing IT disruptions holistically.

The Workflow:

1. Incident: User experiences an issue (e.g., “Server X is intermittently unavailable”). An incident is logged.
2. Problem Identification: The support team notices this issue occurs frequently and affects multiple users or critical functions. They realize it’s not a one-off event.
3. Problem Creation: The support engineer elevates the incident to a Problem record (as discussed in Scenario 2). The original incident(s) are linked to this Problem.
4. Root Cause Analysis (RCA): The Problem Management team investigates the root cause of the intermittent unavailability of Server X. They discover a configuration bug in the server’s network interface card (NIC) driver.
5. Solution Development: The identified solution is to update the NIC driver to a newer, stable version.
6. Change Request Creation: To implement this fix, a Change Request is created, linking back to the Problem record. This Change Request details the planned action: “Update NIC driver on Server X.”
7. Change Implementation: The Change Management team schedules and executes the change. This might involve downtime, testing, and verification.
8. Problem Resolution: Once the change is successfully implemented and verified, the Problem record is resolved.
9. Incident Resolution: Since the Problem is resolved, all linked incidents (representing the intermittent unavailability) are also automatically resolved or closed, as the underlying cause has been fixed.

ServiceNow Implementation:

Reference point 29) perfectly describes this relationship. ServiceNow’s design facilitates this by allowing:

• Linking Incidents to Problems.
• Linking Problems to Changes.
• Linking Incidents to Changes (directly or indirectly via Problems).

These relationships are managed through reference fields on the respective records, allowing for traceability and impact analysis.