Mastering ITIL Incident Management: A Human-Centric Guide to Keeping Services Running

Ever had that sinking feeling when your essential work tool suddenly decides to take an unannounced break? Maybe your email stops syncing, your application crashes, or your network connection mysteriously vanishes. For most of us, it’s a frustrating interruption, but for IT professionals, it’s a call to action – a signal that an incident has occurred. In the world of IT Service Management (ITSM), and specifically under the widely adopted ITIL framework, dealing with these unexpected service interruptions falls squarely under the domain of Incident Management.

This article aims to peel back the layers of ITIL Incident Management, offering a detailed, human-like perspective that goes beyond mere definitions. We’ll explore its core concepts, its intricate dance with other ITIL processes like Problem and Change Management, and dive into practical, real-world applications within platforms like ServiceNow. Whether you’re an IT support engineer, a service desk agent, a developer scripting solutions, or just someone looking to understand how IT keeps the lights on, this guide is for you.

What Exactly is an Incident? The Sudden Hiccup

Let’s start with the basics. What defines an “incident” in the ITIL context? Simply put, an incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service. Think of it this way: you’re working diligently, and suddenly, something stops working as it should. Your printer jams, your internet connection drops, or a critical application refuses to launch. That immediate, unexpected disruption to your work? That’s an incident.

The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, ensuring that the best possible levels of service quality are maintained. It’s all about getting you back to productivity with minimal fuss.

Incident vs. Problem: Unpacking the “Why” Behind the “What”

This is a classic distinction and a frequent topic in ITIL certifications and interviews. While an incident is about the immediate disruption, a problem delves deeper.

• Incident: A single, sudden interruption. “My email isn’t working right now!”
• Problem: The underlying cause of one or more incidents. If your email consistently stops working every Tuesday morning for the past month, that repeated failure points to an underlying problem, not just a series of isolated incidents.

Here’s a crucial nuance: if the “same problem” (meaning the same symptom or impact) is happening to multiple people at the same time, it’s still initially an incident from each user’s perspective. However, the IT team will quickly recognize it as a major incident or a widespread issue. In such cases, they might create a parent incident to track the overall outage and link all individual user reports to it as child incidents. This approach streamlines communication and resolution; when the parent incident is resolved, all associated child incidents are automatically closed.

The key takeaway? Incidents are about restoring service. Problems are about understanding and eliminating the root cause to prevent future incidents.

The Interconnected World: Incident, Problem, and Change Management

ITIL isn’t a collection of isolated processes; it’s an integrated framework. Incident Management rarely works in a vacuum. It often serves as the entry point into a broader cycle of improvement. Let’s explore its relationships:

Creating a Problem Record from an Incident

Yes, absolutely! This is a cornerstone of proactive IT management. If the support team identifies that an issue is repeatedly occurring – perhaps the “email down” incident happens several times a week for the same user or even different users – they will raise a problem record from that incident. This signals a shift in focus from quick fix to root cause analysis. Problem Management then takes over, aiming to find out *why* the email keeps failing and to implement a permanent solution.

Creating a Change Request from an Incident

This also happens frequently. Imagine an incident where a critical system crashed because of an outdated driver. The support engineer might quickly roll back to a stable version to restore service (resolving the incident). However, they might then realize that a permanent fix or upgrade is required to prevent future crashes. This structural modification or update to an IT service or component is managed through a change request. So, after an incident is resolved, if the support engineer believes a software update, a configuration change, or new hardware is necessary to prevent recurrence or improve stability, they’ll initiate a change request directly from that incident.

The Holistic Relationship

To summarize the grand picture: A user faces an issue and creates an incident. If this issue is recurring, it escalates to a problem. If the solution to that problem (or even a workaround for an incident) requires a modification to the IT infrastructure or services, a change request is initiated. This cycle ensures that IT not only fixes what’s broken but also learns from failures and continuously improves its services.

Getting Technical: Incident Management in ServiceNow (and Beyond)

While the principles of ITIL are universal, their application often involves powerful ITSM platforms like ServiceNow. Here, we’ll dive into how these concepts translate into practical scripting and configuration.

Creating Records Using Script: The GlideRecord Powerhouse

ServiceNow developers live and breathe GlideRecord. It’s the API for interacting with the database. Creating records for Incidents, Problems, or Change Requests programmatically is a fundamental skill. This is particularly useful for integrations, automated processes, or bulk data operations.

Creating an Incident Record:

To create a new incident, you’d initialize a new GlideRecord object for the ‘incident’ table, populate its fields, and then insert it.

var gr = new GlideRecord('incident');
gr.initialize(); // Prepares a new record for insertion
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the affected Configuration Item
gr.short_description = 'Test record using script: Network problem';
gr.description = 'This is a detailed description of the network problem encountered, created via script.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
gr.insert(); // Commits the new record to the database
gs.info("New Incident created: " + gr.number);
    

Notice how `initialize()` sets up an empty record, and `insert()` saves it. For `caller_id`, `cmdb_ci`, and `assignment_group`, we typically use the `sys_id` of the referenced record, although `setDisplayValue()` can also be used for convenience when you only have the display name (e.g., `gr.caller_id.setDisplayValue(‘Joe Employee’);`).

Creating a Problem Record:

The process is remarkably similar, just targeting the ‘problem’ table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // While problems don't always have a direct caller, this might be linked for context.
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test record using script: Recurring email issue';
gr.description = 'Problem record created to investigate repeated email sync failures.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info("New Problem created: " + gr.number);
    

Creating a Change Request:

And for a change request, we target ‘change_request’:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test record using script: Upgrade server OS';
gr.description = 'Change requested to upgrade the operating system of the web server after stability issues.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info("New Change Request created: " + gr.number);
    

Advanced Scripting Scenarios: Automating Workflow Logic

This is where ServiceNow truly shines, allowing for powerful automation to enforce ITIL best practices.

Automating Child Incident Closure when Parent Closes

Remember our parent/child incident discussion? It’s inefficient to manually close dozens of child incidents. This logic is typically implemented using an “After” Business Rule on the Incident table.

Business Rule Configuration:

• When: After
• Update: True (This rule should run when an incident is updated)
• Condition: `current.state.changesTo(7) && current.parent.nil()` (Assuming ‘7’ is the `sys_id` value for ‘Closed’ state in your instance. `current.parent.nil()` ensures it only runs for parent incidents.)

Script:

// This script will run after an incident is updated, if its state changes to 'Closed' and it has no parent.
if (current.state == 7 && current.parent.nil()) { // Check if the current incident is closed and is a parent
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find all incidents where 'parent' field references the current incident's sys_id
    grChild.query();
    while (grChild.next()) {
        if (grChild.state != 7) { // Only close if not already closed
            gs.info('Closing child incident ' + grChild.number + ' due to parent ' + current.number + ' closure.');
            grChild.state = 7; // Set the state to Closed (ensure '7' is the correct value for 'Closed' in your instance)
            grChild.update(); // Update the child incident
        }
    }
}
    

Interview Relevance: This is a very common interview question to test your understanding of Business Rules, GlideRecord, and basic workflow automation.

Preventing Record Closure with Open Tasks

Imagine trying to close an incident, problem, or change request while there are still outstanding tasks associated with it. This is generally bad practice and can lead to incomplete resolutions. You can prevent this using a “Before” Business Rule.

Business Rule Configuration:

• When: Before
• Update: True
• Condition: `current.state.changesTo(7)` (or whatever the ‘Closed’ state value is for your table)

Script (Example for Incident with Incident Tasks):

// This script runs before an incident is updated to 'Closed'.
if (current.state.changesTo(7)) { // Assuming '7' is the state value for 'Closed'
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id); // Query tasks linked to this incident
    grTask.addQuery('state', '!=', 3); // Assuming '3' is the state value for 'Closed' tasks
    grTask.query();

    if (grTask.hasNext()) { // If any open tasks are found
        gs.addErrorMessage('Cannot close the incident because there are open tasks. Please close all associated tasks first.');
        current.setAbortAction(true); // Prevents the incident from being saved/closed
    }
}
    

You would implement similar Business Rules on the `problem` table (checking `problem_task` records) and `change_request` table (checking `change_task` records).

Troubleshooting Tip: Always double-check the numerical values for states (e.g., ‘7’ for Closed, ‘3’ for Complete/Closed) in your ServiceNow instance, as they can vary slightly with customizations or versions. You can find these by inspecting the ‘Choice’ list for the ‘state’ field.

Closing Associated Incidents when a Problem is Closed

When the root cause is resolved (i.e., the problem record is closed), any incidents linked to it should also be closed, as their underlying issue has been addressed. This is another “After” Business Rule scenario on the Problem table.

Business Rule Configuration:

• When: After
• Update: True
• Condition: `current.state.changesTo(7)` (Assuming ‘7’ is the ‘Closed’ state for problems)

Script:

// This script runs after a problem is updated, if its state changes to 'Closed'.
if (current.state == 7) { // Check if the problem is closed
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Find incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Only close incidents that aren't already closed
    grIncident.query();
    while (grIncident.next()) {
        gs.info('Closing incident ' + grIncident.number + ' due to problem ' + current.number + ' closure.');
        grIncident.state = 7; // Set incident state to Closed
        grIncident.update(); // Update the incident
    }
}
    

Interview Relevance: This demonstrates a good understanding of process integration and automation, crucial for an efficient IT department.

Fetching Records: Getting the Data You Need

Fetching the Last 5 Incidents:

This is a common reporting or dashboard requirement. `orderByDesc()` and `setLimit()` are your friends here.

var gr = new GlideRecord('incident');
gr.orderByDesc('sys_created_on'); // Order by creation date, newest first
gr.setLimit(5); // Get only the top 5
gr.query();

gs.info('Last 5 incidents created:');
while (gr.next()) {
    gs.info(gr.number + ' - ' + gr.short_description + ' (Created On: ' + gr.sys_created_on + ')');
}
    

Other Core GlideRecord Operations

• Updating Records: Query the record(s), set new values, and call `update()`.

  
  var gr = new GlideRecord('incident');
  gr.addQuery('number', 'INC0010001'); // Find a specific incident
  gr.query();
  if (gr.next()) {
      gr.short_description = 'Updated description: Network issue resolved.';
      gr.update();
      gs.info('Incident ' + gr.number + ' updated.');
  }
              

• Deleting Records: Query the record(s) and call `deleteRecord()`.

  
  var gr = new GlideRecord('incident');
  gr.addQuery('active', false); // Find all inactive incidents
  gr.setLimit(10); // Limit deletion to avoid accidental mass deletion
  gr.query();
  while (gr.next()) {
      gs.info('Deleting incident: ' + gr.number);
      gr.deleteRecord();
  }
              

Specialized GlideRecord and Query Techniques

Encoded Query:

Encoded queries allow you to build complex ‘filter-like’ conditions programmatically. If you’ve ever used the filter builder in ServiceNow, an encoded query is the string representation of that filter.

// Find all active incidents where the category is software OR hardware
var gr = new GlideRecord('incident');
var strQuery = 'active=true';
strQuery = strQuery + '^category=software';
strQuery = strQuery + '^ORcategory=hardware'; // ^OR is crucial for 'OR' conditions
gr.addEncodedQuery(strQuery);
gr.query();

gs.info('Incidents matching encoded query:');
while (gr.next()) {
    gs.info(gr.number + ' - ' + gr.short_description);
}
    

getRefRecord(): A Shortcut for Referenced Records

When you have a reference field (like `caller_id` on an incident, which references the `sys_user` table), `getRefRecord()` can directly give you a GlideRecord object for that referenced record without needing a separate `GlideRecord` query.

var grIncident = new GlideRecord('incident');
grIncident.get('INC0010001'); // Get a specific incident
if (grIncident.next()) {
    var caller = grIncident.caller_id.getRefRecord(); // Returns the GlideRecord for the caller
    if (caller.next()) { // You still need to call next() if you want to operate on the fetched record
        gs.info('Caller Name: ' + caller.name + ', Current Email: ' + caller.email);
        caller.email = 'updated_email@example.com';
        caller.update();
        gs.info('Caller email updated.');
    }
}
    

This is much cleaner than: `var grUser = new GlideRecord(‘sys_user’); grUser.get(current.caller_id);`

Service Level Agreements (SLAs): The Promise of Service

SLAs are contracts that define the level of service expected from IT. In Incident Management, they are critical for ensuring timely resolution and communication.

Actual Elapsed Time vs. Business Elapsed Time

This distinction is vital for accurate reporting and adherence to service agreements:

• Actual Elapsed Time: This calculates time on a continuous, 24×7 basis. If an incident is opened at 5 PM on Friday and resolved at 9 AM on Monday, the actual elapsed time would include the weekend hours.
• Business Elapsed Time: This calculates time based on a predefined schedule. If the IT team only works Monday-Friday, 9 AM – 5 PM, then the business elapsed time for the above example would only count the hours within that schedule, excluding the weekend. The schedule is typically specified in the SLA definition.

What if no schedule is attached to the SLA? If there’s no specific schedule defined for an SLA, then the Business elapsed time will be the same as the Actual elapsed time. It will simply count 24×7 because there’s no schedule to tell it when to stop counting.

Assignment and Routing: Getting the Right People on the Job

Efficiency in Incident Management heavily relies on quickly assigning incidents to the correct team or individual.

Assignment Rules

Assignment Rules automatically assign tasks (like incidents) to specific users or groups based on predefined conditions. For example, an incident with a ‘category’ of ‘Network’ and ‘subcategory’ of ‘VPN’ might automatically be assigned to the ‘Network Operations’ group.

Important Limitations:

• They do not apply to unsaved changes on a form.
• They only apply if the task is not already assigned to another user or group (they won’t overwrite existing assignments).

Assignment Rules vs. Data Lookup Rules

This is another common interview distinction:

• Assignment Rules: Specifically designed for assignment fields (Assign To, Assignment Group). They run relatively early in the form load process and don’t overwrite existing values.
• Data Lookup Rules: A more generic and powerful way to set *any* field value based on conditions.

Key Differences:

• Field Scope: Data lookup rules can change *any* field value, not just assignment fields.
• Timing/Unsaved Changes: Data lookup rules *can* apply to unsaved changes on a form, providing real-time field population as a user fills out the form. Assignment rules require the record to be saved or initialized.
• Overwriting: Data lookup rules can be configured to override existing field values, whereas assignment rules strictly won’t overwrite existing assignments.

Practical Example: You might use a Data Lookup Rule to automatically set an incident’s ‘Priority’ and ‘Assignment Group’ based on the ‘Service’ and ‘Category’ selected by the user, and have this happen immediately as the user selects the values, even before saving.

Communication in Incident Management: Keeping Everyone in the Loop

Clear communication is paramount during an incident, both internally and externally.

Additional Comments vs. Work Notes Fields

These two fields are critical for tracking communication and progress:

• Additional Comments (Customer Visible): This field is used for communication with the end-user (the “customer”). Any user can update this field, and its contents are typically visible to the user who reported the incident (e.g., in the Service Portal). It’s for external updates.
• Work Notes (Internal Only): This field is for internal communication among IT staff. Only ITIL users (or users with specific roles) can update this field, and its contents are NOT visible to the end-user. It’s for technical details, troubleshooting steps, internal discussions, and status updates for the IT team.

Interview Relevance: Understanding this distinction is crucial, as misusing these fields can lead to security breaches (sensitive info in additional comments) or frustrated users (no updates).

Where are additional comments stored? Surprisingly, not directly in the incident record itself for long strings. Additional comments, along with work notes and other journal fields, are stored in the `sys_journal_field` table in ServiceNow. This table efficiently handles the continuous stream of updates to journal entries.

ServiceNow Power-Ups: GlideAggregate, Data Policies, and Self-Service

GlideAggregate: Beyond Basic Queries

GlideAggregate is an extension of GlideRecord that allows you to perform aggregation functions on query record sets. Think of it like SQL’s `GROUP BY` and aggregate functions (`COUNT`, `SUM`, `MIN`, `MAX`, `AVG`). It’s perfect for reporting and analytics.

// Find all active incidents and log a count of records
var gr = new GlideAggregate('incident');
gr.addQuery('active', true);
gr.addAggregate('COUNT'); // Specify the aggregation type
gr.query();
var incidents = 0;
if (gr.next()){ // You still need to call next() to get the aggregate result
    incidents = gr.getAggregate('COUNT');
    gs.info('Active incident count: ' + incidents);
}
    

Counting Incidents by State, Category, and Priority:

This is where GlideAggregate shines for quick insights.

Incident Count by State (updated today):

gs.info('Incident Count by State (Updated Today):');
var grIncident = new GlideAggregate('incident');
grIncident.addEncodedQuery('sys_updated_onONToday@javascript:gs.beginningOfToday()@javascript:gs.endOfToday()'); // Filter for today's updates
grIncident.addAggregate('COUNT','state'); // Group by state and count
grIncident.groupBy('state'); // Crucial for aggregation
grIncident.query();
while(grIncident.next()){
    gs.info(grIncident.state.getDisplayValue() + ' \t' + grIncident.getAggregate('COUNT','state'));
}
    

Incident Count by Category:

gs.info('Incident Count by Category:');
var grIncident = new GlideAggregate('incident');
grIncident.addAggregate('COUNT','category');
grIncident.groupBy('category');
grIncident.query();
while(grIncident.next()){
    gs.info(grIncident.category.getDisplayValue() + ' \t' + grIncident.getAggregate('COUNT','category'));
}
    

Incident Count by Priority:

gs.info('Incident Count by Priority:');
var grIncident = new GlideAggregate('incident');
grIncident.addAggregate('COUNT','priority');
grIncident.groupBy('priority');
grIncident.query();
while(grIncident.next()){
    gs.info(grIncident.priority.getDisplayValue() + ' \t' + grIncident.getAggregate('COUNT','priority'));
}
    

Identifying Duplicate Records:

A good example of how `addHaving` helps filter aggregated results.

gs.info('--- Identifying Duplicate Incident Numbers ---');
var gr = new GlideAggregate('incident');
gr.addAggregate('COUNT', 'number'); // Count occurrences of each 'number'
gr.addHaving('COUNT', '>', 1); // Only interested if the count is greater than 1
gr.groupBy('number'); // Group results by 'number'
gr.query();

while (gr.next()) {
    var number = gr.getValue('number');
    var count = gr.getAggregate('COUNT', 'number');
    gs.info('Duplicate Incident Number: ' + number + ' (Occurrences: ' + count + ')');

    // Now, find and print details of each actual duplicate record
    var duplicateRecords = new GlideRecord('incident');
    duplicateRecords.addQuery('number', number);
    duplicateRecords.query();
    while (duplicateRecords.next()) {
        gs.info('  - Sys ID: ' + duplicateRecords.getValue('sys_id') + ', Created On: ' + duplicateRecords.getValue('sys_created_on'));
    }
}
    

Query Business Rules vs. Display Business Rules

• Query Business Rules: These execute when data is loaded, typically to *modify the query itself* before or after it’s run. They can hide records from users based on conditions. For example, an Out-of-the-Box (OOB) Query BR prevents non-admin users from seeing inactive users. This is powerful for enforcing data security at the query level.
• Display Business Rules: These run after the data has been queried and loaded from the database, but *before* the form is displayed to the user. They are used to populate scratchpad variables or set default values based on the queried record.

Data Policies: Enforcing Data Integrity Everywhere

Data policies are rules that apply to all data entered into the system, regardless of the source. This includes data from forms, import sets, web services, or the mobile UI. They are primarily used to enforce data consistency and mandatory fields.

Example: If your organization requires that a ‘Resolution Code’ and ‘Resolution Notes’ are mandatory fields whenever an incident is closed, regardless of whether it’s closed via the regular form, a web service integration, or an automated process, you would implement a Data Policy. This prevents incomplete resolution information from entering the system, ensuring data quality and auditability.

Self-Service: Empowering Users

“Self-service” refers to systems or processes where users can perform tasks, obtain information, or complete transactions independently, without needing direct assistance from IT staff. In Incident Management, this typically means a user can report an incident, check its status, or even find solutions in a knowledge base, all through a portal.

Benefits: Reduces workload on the service desk, speeds up resolution for simple issues, and improves user satisfaction.

Ticket/Record Creation Channels

Incidents (and other records) can originate from various sources:

• Form: The traditional way, filled out by an IT agent.
• Self-Service Portal/Record Producer: Users create tickets themselves.
• Email: Users send an email, which is converted into an incident.
• API/Script: Programmatic creation, often for integrations or automated alerts.
• Virtual Agent: AI-driven chatbots guide users to create or resolve issues.
• Walk-in/Phone: Agent creates record during direct interaction.
• Discovery/Monitoring Tools: Automated systems create incidents when they detect issues.

Record Producer: Your Gateway to Service Requests and Records

Record Producers use the familiar Catalog Item user interface to create records in application-specific tables (like Incident, Problem, Change Request, User, Group, etc.). They provide a user-friendly form that collects specific information and then maps that information to fields on a target table to create a new record.

Example: Instead of asking users to navigate to the “Create New Incident” form directly, you can offer a “Report an Email Issue” Record Producer in your Service Portal. This producer would ask targeted questions (“Which email client are you using?”, “What error message do you see?”), and upon submission, it creates an incident record with those details pre-filled.

Catalog Item vs. Record Producer: When to Use What

This is a frequent point of confusion and an important interview question:

• Catalog Item: Use when you are offering end-users the ability to request a service or item that requires approvals, fulfillment workflows, and potentially involves physical goods or complex provisioning. Think “Request a New Laptop,” “Order Software License,” or “Request VPN Access.” These typically involve `sc_request`, `sc_req_item`, and `sc_task` tables.
• Record Producer: Use when you are simply looking to gather information or create a new record in a standard ServiceNow table (like Incident, Problem, Change, or even a custom table). It’s about data collection and record creation, not complex fulfillment. Think “Report an Incident,” “Request New User Account,” or “Submit an Idea.”

Key Service Catalog Tables

For deeper dives into the Service Catalog’s inner workings, here are some key tables:

• sc_cat_item: Stores definitions for catalog items and record producers.
• sc_request: The top-level container for a user’s order.
• sc_req_item: Stores individual items within a request (requested items).
• sc_task: Tasks associated with fulfilling a requested item.
• item_option_new: Stores definitions for variables used in catalog items/record producers.
• sc_item_option: Stores the values submitted for variables on a request item.
• sc_item_option_mtom: Many-to-many relationship between requested items and variable options.
• sc_multi_row_question_answer: Stores data for multi-row variable sets.

Conclusion: The Human Art of Keeping IT Running

ITIL Incident Management isn’t just a set of rules; it’s the heartbeat of an IT organization, ensuring that when things inevitably go wrong, there’s a clear, efficient, and well-orchestrated plan to get services back on track. From understanding the nuanced difference between an incident and a problem to leveraging powerful scripting capabilities in platforms like ServiceNow, every aspect plays a crucial role in minimizing disruption and maintaining user satisfaction.

By understanding the interconnectedness with Problem and Change Management, mastering the practicalities of scripting, and optimizing communication channels, IT professionals can transform what could be chaotic outages into manageable, learning opportunities. It’s about restoring service, yes, but also about building a more resilient, reliable IT environment for everyone. Keep those services running smoothly, and remember: every incident is a chance to learn and improve!