Incident Management
The core job
An incident is an unplanned interruption to, or degradation of, a service. Success is measured by how quickly service is restored, not by whether the underlying cause is found - that is Problem Management's job. Incidents carry CI, service, and service offering references so reporting and SLAs can be scoped.
Priority is derived, not entered
Impact (how much is affected) multiplied by urgency (how quickly the business needs it) resolves through the impact/urgency matrix to a priority of 1 to 5. Impact is breadth and severity; urgency is time sensitivity. Traps: assuming priority can simply be keyed in, or that urgency equals the caller's stated annoyance level.
States and pause logic
New, In Progress, On Hold, Resolved, Closed. On Hold requires a hold reason such as awaiting caller, awaiting problem, awaiting change, or awaiting vendor - and SLAs typically pause while on hold. Resolved requires a resolution code and resolution notes. Closed follows either caller confirmation or automatic closure after a configured number of days. Reopening a resolved or closed incident returns it to an active state and can restart SLA timing.
Operating at scale
Major incident management uses the major incident candidate flag plus the major incident workbench for communications and coordination. Incident tasks split work into subtasks, parent/child links group related incidents, and actions such as Create Problem, Create Change, and Create Knowledge link records across modules.
Worked example
The payroll application is down for the entire finance team two days before payday: high impact, high urgency, priority 1. A single user cannot print: low impact, low urgency, priority 4 or 5. Rule of thumb: if the question is how much is broken, that is impact; if it is how fast we need it, that is urgency.