ServiceNow Incident management

An incident is an unplanned interruption or degradation of a service. It lives on the incident table, which extends task, inheriting number, assignment group, state and priority, and adding caller, category, impact, urgency, resolution code/notes. Crucially, a request for something new is not an incident, it belongs in the Service Catalog.

The boundary that causes the most argument in practice is incident against request, and it is worth being precise because the two have different targets, different queues and different reporting.

An incident is something broken: a service is not working as it should. A request is something wanted: access, equipment, a new account. The test is whether the service was working correctly before. Somebody who never had access to a system is not experiencing an outage, however urgently they need it.

The reason this matters beyond taxonomy is that mixing them destroys your metrics. Mean time to resolve becomes meaningless when half the records are requests waiting on a purchase order, and a genuine spike in incidents is invisible inside a volume dominated by password resets. Teams that cannot see their own outage trend usually find this is why.

The other boundary is incident against problem. Incident restores service. Problem finds the cause. The same event often justifies both, and conflating them produces incidents that stay open for weeks while somebody investigates, with the user waiting for a fix they did not need.

Agents don't pick priority directly, it is calculated from a Priority lookup of Impact x Urgency, keeping prioritisation consistent org-wide:

The mapping is a Priority Data Lookup table you can tune per organisation.

Worth saying why the derivation exists rather than just that it does. Impact is how much of the business is affected: one person, a team, a site, everybody. Urgency is how quickly it needs attention given what that thing does. The matrix combines them, and priority is the output.

Making priority a typed field instead moves the decision to whoever raises the ticket, and their answer is predictable: everything is high. Not because they are unreasonable, but because their problem is the one in front of them. A derived priority moves the decision to a policy the business agreed once, applied the same way to everybody.

The failure mode to watch for is a matrix nobody believes. If most incidents land at the same priority, the matrix is not discriminating and every queue is sorted by nothing. Two checks worth running: the distribution across priorities, and whether the incidents that actually hurt the business were the ones marked highest.

Where it lives: impact and urgency are fields on the incident, the mapping is configuration, and the service the incident names should carry a criticality that feeds it. That last link is why CMDB quality turns up in a conversation about incident priority.

State movement is governed by UI/data policies and business rules (e.g. resolution notes become mandatory at Resolved), and timers are tracked by SLAs.

Two states carry most of the trouble.

On hold, or awaiting something, is where incidents go to disappear. It usually stops the clock, which is correct when you are genuinely waiting on the customer or a third party, and it is also the easiest way to make a breached target look met. A healthy process defines exactly which reasons justify it and reports on how long records spend there.

Resolved is not closed, and the gap between them exists so the person who reported it can disagree. Automatic closure after a period is normal and sensible; automatic closure after a period so short that nobody could have responded is a way of manufacturing a resolution rate.

The related discipline is the resolution record itself. What was wrong, and what was done. A resolution note reading fixed is a record that the incident ended, not a record of anything anybody can learn from, and it is the reason knowledge bases stay empty while the same problem is solved fifty times.

An hour with a list view and a few groupings tells you more about a service desk than any dashboard does.

1. Group last month's incidents by category. If one category holds most of the volume, either it is real or your categories are not distinguishing anything.
2. Group by priority. Look for the flat distribution described above.
3. Find incidents resolved in under five minutes. Many of these are requests in the wrong queue, or questions.
4. Find incidents reopened after resolution. Each one is either a premature closure or a fix that did not work, and the ratio matters.
5. Count how many name a configuration item. Without that, none of them can be correlated with changes or with each other.
6. Take the ten most frequent short descriptions. That list is your automation and knowledge backlog, in priority order, for free.

Step six is the highest value output of the whole exercise. The most common incident on almost every service desk has an obvious fix that nobody has written down, and the list tells you which one to write first.

What makes a major incident different is not severity alone but that the coordination becomes the work. Someone runs the response, someone communicates outward, and the technical people are left alone to fix it. Without those roles named in advance, the most senior person present ends up doing all three badly.

The trigger should be defined rather than judged in the moment: a priority threshold, a named service, or a declaration by a specific role. And the communication cadence should be fixed, because the single largest complaint during a real outage is not the outage, it is the silence.

• A recurring incident feeds Problem Management to find root cause.
• A fix that changes production requires a change.
• A known fix is captured as a knowledge article to deflect the next one.
• An Event Management alert can open incidents automatically.

• Using incidents for service requests, those belong in the catalog.
• Letting agents override priority instead of setting impact/urgency correctly.
• Resolving without a resolution code, so trend reporting is useless.
• No MIM process, so major outages are coordinated over ad-hoc chat.

Two more worth naming. Closing without a usable resolution note, which is how the same incident is solved repeatedly by different people. And measuring volume as if lower is always better: a fall in incidents can mean the estate got more stable, or it can mean people stopped reporting because reporting achieved nothing. Those are opposite conditions and the number looks identical, so pair it with something that distinguishes them.

Version note: ITIL 4 uses the term incident management still, while several neighbouring practices were renamed, so older material and current material sit side by side with different vocabulary for the same things. The platform also now offers generative assistance for summarising and resolving incidents, which is licensed separately and may not be present on your instance. The process described here is unchanged by either.

Configuring the lifecycle takes a day, and building a process whose numbers a business can actually act on is the work the course covers.