Incident Management
About 25% of the CIS-ITSM exam — see all 6 domains.
Purpose and where it lives
Incident Management exists to restore normal service operation as quickly as possible while minimizing business impact. That is the single most-tested distinction: incidents are about speed of restoration, not about fixing the underlying cause (that is Problem Management). A workaround that gets the user productive again is a perfectly good incident resolution even when the root cause is unknown.
Incident records live on the incident table, which extends the base task table. Because of that inheritance, incidents share the task data model's common fields (number, state, assignment group, assigned to, work notes, comments, SLA attachment) with the rest of ITSM. Knowing the table inheritance chain (task → incident) matters for any question about fields, business rules, ACLs, or extending the model.
State model and lifecycle
The baseline incident state model moves a record through New → In Progress → On Hold → Resolved → Closed, with Canceled available for records logged in error. Two states cause the most confusion:
- On Hold pauses active work and requires an On Hold reason (Awaiting Caller, Awaiting Change, Awaiting Problem, Awaiting Vendor). Selecting a reason is what distinguishes a legitimate hold from simply stalling.
- Resolved means a fix or workaround has been applied and the incident is awaiting confirmation/auto-closure. Closed is the terminal state. Baseline behavior auto-closes resolved incidents after a configurable number of days (a system property), and resolution information (resolution code and resolution notes) is mandatory before resolving.
Priority, Impact, and Urgency
Priority is derived, not typed. It is calculated from the combination of Impact and Urgency through the Priority data lookup (Priority Lookup Rules in the data-lookup definitions), executed by a business rule. To let analysts set priority manually, you disable or modify those lookup rules and the recalculation business rule — you do not make the field read-only and you never delete the field. Knowing this calculation pipeline (Impact + Urgency → lookup → Priority) is a recurring exam theme.
Assignment
Incidents reach the right team through assignment rules, assignment groups, and (optionally) Predictive Intelligence / Agent Assignment. The assignment group drives queueing; the assigned-to person owns the work. VIP callers and affected CIs can influence impact/urgency through additional rules, but they do not by themselves set priority.
Major Incident Management (MIM)
A Major Incident is a high-impact, high-urgency incident requiring coordinated, accelerated response. ServiceNow MIM lets an authorized user (the Major Incident Manager) propose an incident as a candidate, after which it is promoted (confirmed) to a major incident; it can later be demoted if it no longer qualifies. MIM adds communication and coordination tooling: a major incident workbench / overview, communication tasks and stakeholder updates, and (in Service Operations Workspace) on-call engagement. After resolution, a Post Incident Review (PIR) report can be generated to capture timeline, contributing factors, and follow-up actions — this is the bridge into Problem Management.
Workspaces and channels
Modern incident work happens in Service Operations Workspace (SOW) (and historically the Agent Workspace), giving agents a list/form/inbox layout, agent assistance, and guided resolution. Incidents are created across channels — agent-logged, self-service portal, virtual agent, email inbound actions, and event/alert integrations from IT Operations Management.
Exam focus
- Purpose = restore service fast (vs. Problem = root cause).
incidentextendstask.- State flow and the meaning of On Hold (with reason) vs. Resolved vs. Closed.
- Priority = Impact × Urgency via data lookup + business rule; how to make it manual.
- Major incident propose → promote → demote; PIR follows resolution.
Sample questions from this domain
Three of the 75 in this domain, with the reasoning. The full set is in the question bank.
What is the primary objective of the Incident Management process in ServiceNow ITSM?
- A. To maintain accurate records of all configuration items
- B. To identify and remove the root cause of recurring issues
- C. To control the lifecycle of all changes to the IT environment
- D. To restore normal service operation as quickly as possible while minimizing business impact ✓
Why: Incident Management is focused on restoring normal service operation as quickly as possible to minimize the adverse impact on business operations. Identifying and removing root cause is the goal of Problem Management (A). Controlling the lifecycle of changes is Change Management (C). Maintaining CI records is the purpose of the CMDB (D).
On which table are incident records stored in the ServiceNow platform?
- A. sn_incident_record
- B. sys_incident
- C. task
- D. incident ✓
Why: Incident records are stored on the 'incident' table, which extends the base 'task' table. While task (A) is the parent table that incident extends, incidents themselves live on 'incident'. 'sn_incident_record' (C) and 'sys_incident' (D) are not valid baseline tables.
In the baseline Incident state model, which state indicates that a fix has been applied and the incident is awaiting confirmation before closure?
- A. Resolved ✓
- B. Canceled
- C. In Progress
- D. On Hold
Why: The Resolved state indicates that the resolution has been applied and the incident is pending confirmation/closure. In Progress (A) means work is actively being performed. On Hold (B) pauses work pending information or a third party. Canceled (D) is used when the incident was logged in error or is not valid.