ServiceNow Incident Management: Process, Priority & Roles

Introduction: The Front Line of ITSM

When something breaks at work — email is down, an app is crawling, a laptop will not connect — the process that catches it is ServiceNow Incident Management. Its single goal is to restore normal service as quickly as possible and limit the damage to the business while the issue is live.

It is the highest-volume, most time-sensitive process in ServiceNow ITSM, and one of the most heavily weighted areas on the CIS-ITSM exam. This guide covers the lifecycle, how priority is calculated, assignment, major incidents, and the tables and roles you must know.

What Is an Incident in ServiceNow?

An incident is an unplanned interruption to a service, or a reduction in its quality. The emphasis is on speed and restoration — not on finding the underlying cause, which is the job of Problem Management.

Incidents live in the incident table, which extends the Task table. That inheritance is why every incident shares the familiar fields — Number, State, Assignment group, Assigned to, Work notes, Additional comments — and why incident numbers carry the INC prefix. A related incident_task table (also extending Task) lets you split an incident into smaller units of work.

The Incident Lifecycle (State Model)

The baseline lifecycle runs through these states:

State	Meaning
New	Logged but not yet assigned or worked
In Progress	Assigned and actively being worked
On Hold	Paused — requires an On hold reason
Resolved	A fix has been applied; awaiting confirmation
Closed	Confirmed resolved and finalized
Canceled	Logged in error / not a genuine incident

When state is set to On Hold, a UI policy reveals the On hold reason field, whose options are Awaiting Caller, Awaiting Change, Awaiting Problem, and Awaiting Vendor. Best practice: code against the State field (not the legacy Incident State) using constants rather than raw values — State is available across all task types, which makes cross-process reporting easier.

How Priority Is Calculated: Impact × Urgency

Priority is never set directly. It is derived from two inputs via the Priority Lookup rules:

Input	Question it answers
Impact	How badly is the business affected? (High/Medium/Low)
Urgency	How quickly is a resolution needed? (High/Medium/Low)

To change how priority is calculated, you edit the Priority Lookup rules — not the Priority field itself. This "priority is derived, not typed" point is a classic exam question.

How Incidents Are Created

ServiceNow deliberately offers many front doors:

• Employee Center / portal, and the Incident application or workspace
• Inbound email (an inbound email action creates or updates an incident)
• Virtual Agent / support chat
• Integrations (REST, SOAP, import sets) and event monitoring

Assignment and Routing

Incidents route by Assignment group first, then an individual Assigned to. The Assign to me UI action is smart: if you belong to the filled-in group it assigns to you; if the group is empty and you are in exactly one eligible group it fills that in; if you are in several it prompts you to choose. A business rule can auto-populate the assignment group from the Support group of the affected CI — a strong reason to keep your CMDB healthy.

Major Incident Management (MIM)

A major incident is a high-impact incident that needs a coordinated response beyond the routine process. Activating the Major Incident Management plugin adds a propose/promote workflow, a Major Incident Workbench, communications tooling, and roles such as major_incident_manager. Once service is restored, a major incident usually feeds Problem Management to chase the root cause.

Deflection and Knowledge

Contextual search surfaces related knowledge articles and similar incidents right on the form and portal, helping users self-serve before they ever submit a ticket. When an incident is resolved, agents can generate a knowledge article from it so the next occurrence is faster to fix.

Key Roles in Incident Management

Role	Responsibility
itil	Core fulfiller — creates and works incidents
itil_admin	Advanced administration of the ITIL apps
incident_manager	Owns the incident process
major_incident_manager	Runs major incidents
sn_incident_read / sn_incident_write	Scoped read/write access

Frequently Asked Questions

Which table stores incidents in ServiceNow? The incident table, which extends the base task table — so incidents inherit task fields like State, Assignment group, and Work notes.

How is incident priority set? It is calculated automatically from Impact × Urgency using the Priority Lookup rules. Users do not set Priority directly; to change the calculation you edit the lookup rules.

What does the On Hold state require? An On hold reason — one of Awaiting Caller, Awaiting Change, Awaiting Problem, or Awaiting Vendor — which a UI policy makes visible when State becomes On Hold.

What is the difference between an incident and a problem? An incident is about restoring service fast; a problem investigates the root cause so incidents stop recurring.

What is a major incident? A high-impact incident needing an accelerated, coordinated response, managed with the Major Incident Management plugin and the Major Incident Workbench.

Key Takeaways

• Incident Management is about speed — restore service first, investigate later.
• The incident table extends task; numbers use the INC prefix.
• Priority = Impact × Urgency, derived via Priority Lookup rules, never typed directly.
• On Hold always requires an On hold reason.
• Major incidents get their own plugin, workbench, and roles, and feed Problem Management.

Where to go next

• The natural next step: Problem Management
• See how it all fits: ServiceNow ITSM Modules Explained
• Practise: free ServiceNow CIS-ITSM practice test