What is Incident Management? A Comprehensive Guide

By /






Incident Management: Your Digital Firefighter’s Playbook



Incident Management: Your Digital Firefighter’s Playbook

Imagine this: You’re in the middle of a crucial presentation, your screen suddenly freezes, or perhaps your entire network decides to take an unannounced coffee break. Panic sets in, deadlines loom, and productivity grinds to a halt. Sound familiar? This, my friends, is the realm where Incident Management steps in, armed with protocols, tools, and dedicated heroes ready to restore order from chaos.

In the world of IT Service Management (ITSM), Incidents are the unplanned interruptions that throw a wrench in the works. They’re the unexpected hiccups that disrupt your day, and effective Incident Management is your organization’s robust strategy to get things back on track, minimizing downtime and frustration. It’s not just about fixing things; it’s about a systematic approach to identify, log, diagnose, resolve, and learn from every disruption.

Ready to put on your digital firefighting gear? Let’s dive deep into the fascinating world of Incident Management, especially through the lens of powerful platforms like ServiceNow.

What Exactly is an Incident?

At its core, an incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service. Think of it as anything that prevents an employee from performing their duties effectively because something isn’t working as it should. It’s immediate, it’s often unexpected, and it demands attention.

Let’s paint a picture: Sarah, a marketing specialist, is trying to upload her latest campaign video, but the company’s file server is completely unresponsive. This sudden interruption means she can’t do her job. What does she do? She reaches out to the IT support team, typically by creating an “incident ticket” or “incident record.” This ticket becomes the digital fingerprint of her problem, allowing support engineers to track, diagnose, and resolve the issue. If the server suddenly stopped working, that’s an incident.

Interview Question Alert: Often, the first question in an ITSM interview is, “What is an incident?” Your ability to provide a clear, concise definition with a real-world example demonstrates foundational knowledge.

When Does an Incident Become Something More? Incident vs. Problem

This is where things get interesting, and it’s a critical distinction in the world of ITSM. While an incident is about restoring service as quickly as possible, a “problem” delves deeper.

Imagine Sarah’s file server issue from before. If the server goes down once, it’s an incident. But what if it keeps going down every Tuesday morning, or every time a large video file is uploaded? If the same issue is repeatedly happening to the same employee, or even worse, if the same issue is happening to multiple people at the same time, then we’re no longer just dealing with an incident; we’re staring at a problem.

A problem is the underlying cause of one or more incidents. Incident management focuses on the “what” (the service is down, fix it!). Problem management focuses on the “why” (why does the service keep going down, and how can we prevent it permanently?).

Parent-Child Incidents: When Chaos Spreads

Sometimes, an incident isn’t isolated. That file server going down might affect not just Sarah, but the entire marketing department, or even the whole company. In such scenarios, instead of logging dozens of identical incidents, we create a single “parent incident.” This parent incident captures the widespread impact, and all the individual reports from affected users become “child incidents.”

This approach offers several benefits:

  • Consolidation: Prevents the service desk from being overwhelmed by duplicate tickets.
  • Unified Communication: Updates on the parent incident automatically apply to all child incidents, keeping everyone informed.
  • Efficient Resolution: Once the root cause addressed by the parent incident is resolved, all associated child incidents can be closed simultaneously.

In ServiceNow, this relationship is often automated: “whenever you close the parent incident, the child incidents will also get closed.” This ensures consistency and saves valuable time for support engineers.

From Incident to Problem: Proactive Prevention

The beauty of a well-integrated ITSM system like ServiceNow is its ability to connect these dots. If your support team keeps seeing the same incident pop up repeatedly, it’s a red flag. That’s why, in ServiceNow, if an issue is recurring, you can easily create a problem record directly from an incident. This escalation signals to the team that it’s time to move beyond quick fixes and start root cause analysis.

Interview Question Alert: Understanding the incident-problem relationship is a common topic. Be prepared to explain how a repeated incident leads to a problem and the purpose of creating a problem record.

From Incident to Change: Continuous Improvement

Sometimes, fixing an incident isn’t enough. The incident might reveal a fundamental flaw in the system, a piece of software, or a process that needs a permanent alteration. If a support engineer feels there should be some change in the software, hardware, or configuration to prevent future incidents or improve service quality, they can create a change request from that incident.

A “change request” is a formal proposal for an alteration to an IT service or infrastructure. It’s a controlled process to ensure that any modification is planned, approved, tested, and implemented without causing further disruption. For example, if an incident highlights that an outdated server is consistently failing, the resolution might involve replacing it – a significant change that requires a formal change request.

The Grand Relationship: Incident, Problem, and Change Management

These three processes are the pillars of effective ITSM, working hand-in-hand:

  1. A user faces an issue and creates an Incident.
  2. If the same issue keeps happening, it’s elevated to a Problem to find the root cause.
  3. Once the root cause is identified, if a modification to the system is needed to prevent recurrence, a Change Request is initiated.

They form a continuous improvement loop: Incident (reaction) -> Problem (analysis) -> Change (prevention).

Crafting Records in ServiceNow: The Art of Digital Documentation

ServiceNow is a powerful platform for managing these processes, and knowing how to create and manipulate records is fundamental. You can create records in many ways:

  • Through a Form: The most common way for users and support staff via the portal or backend interface.
  • Record Producers: Specialized forms in the service portal that create records in various tables.
  • Email: Configuring inbound email actions to automatically generate incidents from user emails.
  • Excel Sheets/Data Imports: For bulk creation or migration.
  • From External Systems: Via integrations (APIs, web services).
  • Using Scripts (GlideRecord): For automation and advanced scenarios, which we’ll explore next.

Automating Record Creation with GlideRecord

For developers and administrators, scripting is where ServiceNow truly shines. GlideRecord is ServiceNow’s fundamental API for interacting with the database, allowing you to query, insert, update, and delete records. Let’s look at how you’d create an Incident, Problem, or Change Request using a script.

Creating an Incident Record via Script

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the user
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the 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();
gs.info("Incident " + gr.number + " created successfully.");

Troubleshooting Tip: When scripting, always ensure you’re using the correct sys_id for reference fields (like caller_id, cmdb_ci, assignment_group). A wrong sys_id will either fail or point to the wrong record. Also, verify field names are accurate (e.g., short_description, not shortDescription).

Creating a Problem Record via Script

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'test problem record using script';
gr.description = 'test problem record using script';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info("Problem " + gr.number + " created successfully.");

Creating a Change Request Record via Script

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'test change request using script';
gr.description = 'test change request using script';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info("Change Request " + gr.number + " created successfully.");

Notice the slight difference: a Change Request typically doesn’t have a caller_id in the same way an Incident or Problem does, as it’s often initiated by internal teams rather than an end-user reporting an issue.

Automating Incident & Problem Relationships with Business Rules

The true power of ITSM platforms comes from automating complex workflows. Business Rules are server-side scripts that run when a record is displayed, inserted, updated, or deleted. They are perfect for enforcing policies and automating relationships.

Closing Child Incidents When Parent Closes (Q26)

This is a classic scenario for a Business Rule. When a parent incident is resolved, we want all its children to follow suit. This rule would run “After” an “Update” on the Incident table, specifically when the `state` changes to `Closed (7)`.

// Business Rule: Close Child Incidents
// When: After, Update
// Condition: current.state.changesTo(7) && current.parent.nil() (or current.parent == '')

if (current.state == 7 && current.parent.nil()) { // Ensure it's a top-level parent incident
    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
        gs.info("Child incident " + grChild.number + " closed from parent " + current.number);
    }
}

Explanation: The `current.parent.nil()` check ensures this only runs for actual parent incidents, not child incidents that might get updated. `current.state.changesTo(7)` is a powerful method to trigger the rule only when the state *changes to* 7, preventing unnecessary execution if the state is already 7 and the record is merely updated.

Preventing Incident Closure with Open Tasks (Q27)

Sometimes, an incident is broken down into smaller “tasks” for different teams. You wouldn’t want to close the main incident if related tasks are still pending. This requires a “Before” Business Rule to prevent the action.

// Business Rule: Prevent Incident Closure with Open Tasks
// When: Before, Update
// Condition: current.state.changesTo(7)

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. Please close all tasks first.');
    current.setAbortAction(true); // This stops the update operation
}

Note: The state value `3` for ‘Closed’ is an example. Always verify the actual integer value for ‘Closed’ in your ServiceNow instance’s `incident_task` state field. This logic can be extended to `problem_task` for Problems and `change_task` for Change Requests.

Closing Associated Incidents When Problem Closes (Q28)

When the root cause (the Problem) is finally resolved, all the incidents it caused should ideally be closed too. This is another “After” Business Rule, this time on the `Problem` table.

// Business Rule: Close Associated Incidents on Problem Closure
// On Table: Problem
// When: After, Update
// Condition: current.state.changesTo(7) // Assuming 7 is 'Closed' for Problems

if (current.state == 7) {
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link by problem_id field on incident table
    grIncident.addQuery('state', '!=', 7); // Only close incidents not already closed
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
        gs.info("Incident " + grIncident.number + " closed from problem " + current.number);
    }
}

Under the Hood: ServiceNow Tables and Relationships

To truly master Incident Management in ServiceNow, understanding its underlying data structure is key.

Types of Tables (Q30, Q31, Q32)

  • Out-of-the-Box (OOB) Tables: These are the standard tables that come with ServiceNow, like `incident`, `problem`, `change_request`, `user`, `group`, etc. They don’t start with prefixes like `x_` (for scoped applications) or `u_` (for custom tables). These are your foundational building blocks.
  • Base Tables: These tables don’t extend any other table but are extended by many. Think of them as the ultimate ancestors. The most prominent examples are `Task` (`task`) and `Configuration Item` (`cmdb_ci`). They define common fields and behaviors that many other tables inherit.
  • Task Tables: A prime example of extending a base table. `incident`, `problem`, and `change_request` all extend the `Task` table. This means they inherit common fields like `number`, `short_description`, `description`, `state`, `assigned_to`, `assignment_group`, and many others. This inheritance promotes consistency across different processes.

What Happens When You Extend a Table? (Q35)

When you extend a table, the child table inherits all fields and business logic from the parent. Importantly:

  • No Duplicate `sys_` Fields: System fields like `sys_id`, `sys_created_on`, `sys_updated_by`, etc., are *not* recreated in the child table. They are inherited from the parent. This prevents data redundancy and ensures consistency.
  • The `Class` Field: A crucial field called `sys_class_name` (often just referred to as `class`) is created in the parent table. This field stores the name of the actual table a record belongs to. If a parent table is extended by many children, it will still have only one `sys_class_name` field. This allows you to query the parent table and filter records by their specific child class (e.g., all tasks that are incidents).

Numbering Your Records (Q34)

Ever wondered how incidents automatically get an `INC0000001` format? This is configured at the table level. When creating a new table (or modifying an existing one), you go to the “Controls” tab in the table definition. Here, you can:

  • Provide a Prefix: E.g., `INC` for incident, `PRB` for problem.
  • Set the Number of Digits: This determines the padding (e.g., 7 digits for `0000001`).
  • Check “Auto-number”: This enables the automatic incrementing.

Relationships: How Records Talk to Each Other (Q40)

Data in ServiceNow isn’t isolated; it’s interconnected, forming a web of relationships.

  • One-to-Many Relationship: A classic example is Users and Incidents. One user (the `caller_id`) can report multiple incidents, but each incident is typically assigned to only one user as the reporter. Similarly, one assignment group can be assigned many incidents, but an incident has only one primary assignment group.
  • Many-to-Many Relationship: This is where things get more complex. Consider Incidents and Configuration Items (CIs). An incident can affect multiple CIs (e.g., a network outage affects many servers), and a single CI can be affected by multiple incidents over time. These relationships are often managed through an intermediary “junction table” in the background. Another example could be an incident being associated with multiple “watch list” users.

Refining Your Forms: Dependent Values & Reference Qualifiers

User experience is paramount. ServiceNow provides tools to make forms intelligent and user-friendly, guiding users to select the right information.

Dependent Values: Cascading Choices (Q49)

Dependent values are all about creating cascading dropdowns. You’ve seen them everywhere: select a country, then a state/province, then a city. In ServiceNow, this is used to filter available choices in one field based on the selection in another.

Example:

  1. Parent Field: `Category` (e.g., Hardware, Software, Network).
  2. Dependent Field: `Subcategory`.

If the user selects ‘Hardware’ for Category, the Subcategory dropdown might only show ‘Laptop’, ‘Desktop’, ‘Printer’. If they select ‘Software’, it might show ‘Operating System’, ‘Application’, ‘Database’.

How to Configure: In the dictionary entry of the dependent field (`Subcategory`), you’d set the “Dependent Field” attribute to the parent field (`Category`). Then, when defining the choices for `Subcategory`, you link each choice to a specific value of the `Category` field.

Reference Qualifiers: Filtering Related Records (Q48)

Reference qualifiers are essential for controlling which records appear in reference fields (fields that point to another table, like `Assigned to` or `Configuration Item`). You wouldn’t want to assign an incident to a user who’s no longer with the company, would you?

There are three main types:

1. Simple Reference Qualifier

  • Description: The most basic form, where you apply a fixed filter.
  • Example: In the `Assigned to` field (referencing the `User` table), you might only want to show active users.
  • How to Use: In the reference field’s dictionary entry, simply add a query string.
    active=true

    This would display only active users.

2. Dynamic Reference Qualifier

  • Description: This uses a pre-defined “Dynamic Filter Option” that can adapt based on context, like the current user or other form values.
  • Example: Show only incidents assigned to the same assignment group as the current user.
  • How to Use: First, you create a “Dynamic Filter Option” (System Definition > Dynamic Filter Options), defining the conditions. Then, in your reference field’s dictionary entry, you select this dynamic filter option. This is great for reusable, complex filters.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

  • Description: The most flexible type, using custom JavaScript code to build complex, context-aware queries.
  • Example: Filter the `Configuration Item` field to show only CIs that are ‘Active’, belong to a specific ‘Category’, AND are associated with the `Assignment Group` selected on the current incident.
  • How to Use: In the reference field dictionary entry, select “Advanced” for the reference qualifier and enter JavaScript code that returns a query string.
    javascript: 'assignment_group=' + current.assignment_group + '^priority<3';

    This example would filter CIs by the current incident's assignment group and only show CIs with a priority less than 3.

Differences:

  • Simple vs. Dynamic: Simple is static; Dynamic is context-aware via pre-configured options.
  • Dynamic vs. Advanced: Dynamic uses pre-defined filter options; Advanced allows for completely custom, on-the-fly JavaScript logic. Advanced offers the most power.
  • Simple vs. Advanced: Simple is fixed, easy to set up. Advanced is dynamic, requires scripting, and offers ultimate control.

Dictionary Overrides: Customizing Inherited Fields (Q54)

Remember how child tables inherit fields from parent tables (like `Task`)? What if you want a specific field on a child table (e.g., `Incident`) to behave differently than its parent version? That's where Dictionary Overrides come in.

A dictionary override allows you to change the properties or behavior of an inherited field for a specific child table without affecting the parent table or other child tables.

Example: The `Priority` field might have a default value of `4` on the general `Task` table. However, for `Incident` records, you might want the default `Priority` to be `5` (or a different value) to emphasize the urgency of incidents. You'd create a dictionary override for the `Priority` field on the `Incident` table to set its default value to `5`.

Properties you can override:

  • Default Value: The most common override, setting a different initial value.
  • Read Only: Make a field read-only on the child table, even if it's editable on the parent.
  • Mandatory: Make a field mandatory on the child, even if optional on the parent.
  • Choice List Specifications: Add or remove choices from a dropdown list specifically for the child table.
  • Reference Qualifier: Apply a different reference qualifier to a reference field.
  • Column Label/Name: Change how the field label appears on the child table.
  • Help Tag: Provide specific help text for the field on the child table.
  • And many more! Essentially, you can customize most dictionary attributes for a field on a specific child table.

Interview Question Alert: Dictionary overrides are a common advanced ServiceNow topic. Be ready to explain what they are, why you'd use them, and give examples of properties you can override.

Conclusion: The Human Element in Digital Firefighting

Incident Management is far more than just technical fixes; it's about minimizing disruption, maintaining productivity, and ultimately, keeping the human operations of an organization running smoothly. It's about being prepared for the unexpected, having a clear plan of action, and continuously learning from every glitch and hiccup.

Platforms like ServiceNow provide the robust framework to manage these processes efficiently, automate tedious tasks, and ensure that incidents, problems, and changes are handled with precision. By understanding the core concepts – what constitutes an incident, its relationship to problems and changes, and how to leverage powerful tools like GlideRecord and Business Rules – you're not just a technician; you're a digital firefighter, ensuring your organization can weather any digital storm and emerge stronger.

So, the next time your screen freezes, you'll know that behind the scenes, a well-oiled Incident Management machine is already swinging into action, working to restore your service and get you back to doing what you do best. And that, in a nutshell, is the human heart of effective Incident Management.


Scroll to Top