Incidents
An incident is an unplanned interruption to a service, or a reduction in its quality. The goal of working an incident is to restore normal service as fast as possible.
Creating an incident
Section titled “Creating an incident”At minimum you need a Caller (the person affected), a Short description, and an Impact / Urgency pair. Optional fields refine the picture: Contact type (Phone, Email, Self-service, Walk-in, Monitoring, Virtual Assistant), Category / Subcategory, and the affected Configuration item / Service.
Triage: impact, urgency, priority
Section titled “Triage: impact, urgency, priority”Impact and Urgency are each rated 1 - High / 2 - Medium / 3 - Low. Together they drive Priority (1 - Critical through 5 - Planning) through an impact × urgency matrix — priority is derived automatically whenever impact or urgency changes, though it can be manually overridden when the derived value doesn’t fit the situation. Severity is a separate, independent indicator you can set alongside priority.
Assignment
Section titled “Assignment”Route the incident to an Assignment group, then to an individual Assigned to. Assign to me picks it up as your own with one action.
States
Section titled “States”| State | What it means | Typical next action |
|---|---|---|
| New | Logged but not yet worked. Caller, short description, impact, and urgency are captured. | Start Progress (or Resolve directly for a quick fix) |
| In Progress | Assigned and actively being investigated or diagnosed. | Resolve, or Hold if you’re waiting on something |
| On Hold | Paused, waiting on the caller, evidence, a change, a problem, or a vendor. Requires an on-hold reason. | Resume once the wait is over |
| Resolved | A fix or workaround is in place. Requires a resolution code and resolution notes. Starts the auto-close window. | Close, or Reopen if the issue recurs |
| Closed | Terminal. Resolution confirmed, or auto-closed after the resolution window elapsed. | Reopen if the issue recurs within the reopen window |
| Canceled | Terminal. Logged in error, a duplicate, or withdrawn — no resolution required. | — |
The available actions on a record always match its current state — you’ll see Start Progress on a New incident, Hold/Resolve on one In Progress, Resume on one On Hold, and Close/Reopen on one Resolved.
On-hold reasons
Section titled “On-hold reasons”Putting an incident On Hold requires you to pick a reason: Awaiting Caller, Awaiting Evidence, Awaiting Change, Awaiting Problem, or Awaiting Vendor. Resuming clears the hold.
Resolving
Section titled “Resolving”Resolve is blocked until you provide a Resolution code and Resolution notes — you can’t move an incident to Resolved without both. Resolution codes include Solved (Permanently), Solved (Work Around), Resolved by caller, Resolved by change, Resolved by problem, Resolved by request, Known error, Duplicate, User error, and No resolution provided.
Reopening
Section titled “Reopening”An incident can be reopened from Resolved (back to In Progress) if the issue recurs before it’s closed, or from Closed (back to In Progress) if it recurs after closure, within the reopen window. Each reopen is counted so you can see how many times a given incident bounced back.
Major incident handling
Section titled “Major incident handling”An incident carries a Major incident state field (Proposed / Accepted / Rejected / Cancelled) you can use to flag it as a candidate for major-incident handling.
Separately, the Propose Major Incident and Promote to Major Incident actions open a create form for a distinct Major Incident record, pre-linked back to the triggering incident. That record has its own war-room lifecycle — Proposed, Accepted, Engage / Investigate, Fix in Progress, and Resolved — tracked on the Major Incident Management workbench (reachable from the rail). The workbench shows active majors as cards with KPI counts (active majors, P1 critical, majors still needing a lead, total majors), each card showing the assigned commander, business impact, and affected service.