CodeVerse Creatives
Esc
ServiceNow Syllabus / Module 16 of 25 / Week 16

Week 16: ITSM Core: Incident, Problem & Change Management

Step back from code for a week. Everything you've scripted so far has been in service of processes that exist independently of ServiceNow — incident, problem and change management are ITIL disciplines the platform implements, not inventions of the platform itself. Understanding the process makes every ACL, Business Rule and workflow you build against it make sense as more than arbitrary requirements.

Module 16 of 25 Week 16 of 26 ~3–4 Hours Hands-on Exercise Included

By the end of this week, you'll be able to

  • Explain the incident lifecycle and how priority is derived from impact and urgency
  • Distinguish problem management from incident management and describe root cause records
  • Describe a change record's risk assessment and approval workflow
1 Incident Lifecycle 2 Impact, Urgency & Priority 3 Problem Management 4 Change Management 5 Exercise 6 Knowledge Check

1. The Incident Lifecycle

An incident represents an unplanned interruption or reduction in quality of an IT service — the goal is restoring normal service as fast as possible, not necessarily understanding why it broke (that's problem management's job, next). The standard state progression:

incident.state values (out-of-box)
1 - New
2 - In Progress
3 - On Hold
6 - Resolved
7 - Closed
8 - Cancelled

Every state number you've been reading and setting in Business Rules since Week 5 maps onto this lifecycle — Week 5's state.changesTo(6) example was, concretely, "the incident just got Resolved."

2. Impact, Urgency & Priority

Priority isn't usually set directly by the person logging an incident — it's derived from two separate judgments: Impact (how many people/services are affected) and Urgency (how time- sensitive the fix is), combined through a priority lookup matrix.

conceptual priority matrix
             Urgency: High   Medium   Low
Impact High:     P1        P2      P3
Impact Medium:   P2        P3      P4
Impact Low:      P3        P4      P4

This is typically implemented as its own small lookup table (priority_lookup_rule) that a Business Rule consults on insert/update — a real-world example of "don't hardcode a matrix in script when a configuration table does the same job more maintainably," a design instinct worth carrying into your own scoped apps later.

3. Problem Management

A Problem record exists to find and fix the underlying cause behind one or more incidents — where an incident asks "how do we restore service right now," a problem asks "why did this happen, and how do we prevent it happening again." One problem can have many related incidents linked to it; resolving the problem (with a documented root cause and fix) is a separate lifecycle from resolving any individual incident.

Incidents don't have to wait for problems

A common misconception: incidents get resolved on their own timeline (restore service now), while the linked problem investigation can continue independently, sometimes for much longer, focused on the permanent fix rather than the immediate symptom.

4. Change Management: Risk & Approvals

A Change Request tracks a planned modification to a service or piece of infrastructure — deploying new code, patching a server, reconfiguring a network device. Unlike incidents (reactive) and problems (investigative), changes are proactive and typically require formal approval before implementation, gated by an assessed risk level (often derived from a risk assessment questionnaire, conceptually similar to the priority matrix above) and one or more Approval records that must be granted before the change can move to Implement.

5. Hands-on Exercise

Hands-on

Trace one issue through incident, problem and change

Requirements:

  1. Create an incident with Impact = High and Urgency = High, and confirm the platform derives Priority = 1 (or your instance's equivalent top priority).
  2. Create a Problem record, and link your incident to it via the Problem field on the incident (or the Related Incidents list on the problem).
  3. Resolve the incident, and confirm the linked Problem record remains open and unaffected.
  4. Create a Change Request describing the permanent fix, link it to the Problem, and step it through its approval state to "Implement" (approving as yourself if your instance allows self-approval on a PDI).

6. Knowledge Check

Four quick questions. Expand each to check your answer.

Q1

What's the core difference in goal between an incident and a problem?

An incident's goal is restoring normal service as fast as possible after an unplanned interruption. A problem's goal is finding and fixing the underlying root cause — a slower, more investigative process that can continue after the related incident is already resolved.

Q2

How is an incident's priority typically determined?

It's usually derived, not set directly, from two separate judgments — Impact (how many people or services are affected) and Urgency (how time-sensitive the fix is) — combined through a priority lookup matrix rather than hardcoded logic, so the mapping between impact/urgency and priority stays configurable.

Q3

Why can a linked incident be resolved while its related problem stays open for much longer?

They run on separate lifecycles addressing different questions: the incident is about restoring service now, which can happen quickly, while the problem investigation into the permanent root cause and fix is a separate, often longer-running effort that isn't blocked by the incident already being resolved.

Q4

What distinguishes a Change Request from an incident or a problem?

Changes are proactive rather than reactive or investigative — they track a planned modification to a service or piece of infrastructure, gated by an assessed risk level and formal approvals that typically must be granted before implementation, unlike incidents and problems which respond to something that already happened.

← Back to Week 15 Up next Week 17 →