The four flagship modules of IT Service Management — Incident, Problem, Change, and Knowledge — are the original use cases ServiceNow was built for, and remain its bestselling product line. Every ServiceNow administrator must understand how each works individually and how they relate.
Incident Management
Definition: An unplanned interruption to a service or reduction in its quality.
The goal of incident management is restore service as quickly as possible — not to find the root cause (that is what Problem is for).
Standard incident states
- New
- In Progress
- On Hold (Awaiting Caller / Vendor / Change)
- Resolved
- Closed
- Canceled
Key incident fields
| Field | Purpose |
|---|---|
| caller_id | The user reporting the incident |
| category / subcategory | Routing taxonomy |
| impact / urgency | Inputs to the calculated Priority |
| priority | 1-Critical through 5-Planning, derived from impact × urgency |
| assignment_group / assigned_to | Who is working on it |
| configuration_item (CI) | The affected service/server/application from the CMDB |
| close_code, close_notes | Resolution categorisation |
Major Incident Management (MIM)
For high-severity outages, ServiceNow has a dedicated Major Incident process: dedicated MIM workspace, war room collaboration, post-incident review record (problem record), customer communications via the customer service module.
Problem Management
Definition: The process of investigating the root cause of one or more incidents and preventing recurrence.
Where Incident is reactive and fast, Problem is methodical and analytical.
Problem record lifecycle
- New → Problem identified
- Assess → Investigating
- Root Cause Analysis → Identifying the underlying defect
- Fix in Progress → Solution under development
- Resolved → Permanent fix deployed
- Closed
Known Errors and Workarounds
When a problem's root cause is understood but a permanent fix is not yet available, a Known Error record documents it along with a workaround. Service-desk agents resolving similar incidents can apply the workaround immediately rather than reinvestigating.
Relationship to incidents
Multiple incidents can be linked to one problem. When the problem is resolved with a fix, related incidents are auto-updated. This relationship is critical for proving ROI on the Problem process.
Change Management
Definition: The process of controlled introduction of changes to services to minimise risk and disruption.
Three standard change types
| Type | Risk | Approval |
|---|---|---|
| Standard | Pre-approved, low-risk, repeatable (e.g., password reset, certificate renewal) | Implicit (pre-approved template) |
| Normal | Routine but unique; requires risk assessment | CAB review |
| Emergency | Urgent fix to restore service; reduced lead time | ECAB (Emergency CAB) |
Change record fields
- type (standard / normal / emergency)
- category
- risk and impact (auto-calculated from Risk Conditions)
- implementation plan, backout plan, test plan
- cmdb_ci (the CI being changed)
- start_date and end_date (the change window)
- state — from New through Implement to Review/Closed
Change Advisory Board (CAB)
The CAB is a recurring meeting (often Tuesday afternoon) where the change manager and representatives review upcoming Normal changes. ServiceNow has a built-in CAB Workbench to schedule, agendise, and minute these meetings.
Change Calendar and Blackout Windows
The change calendar displays all scheduled changes; blackout periods (end-of-quarter freeze, holiday weekends) automatically reject change requests that fall within them. This is one of the most-loved features of the module.
Knowledge Management
The Knowledge module stores reusable articles: how-tos, troubleshooting steps, FAQs, policy documents. Articles live in knowledge bases (e.g., IT Knowledge, HR Knowledge, Customer-facing Knowledge), each with its own permissions.
Article lifecycle
- Draft
- Review
- Published
- Retired
Two consumption modes
- Search: End users search the knowledge base; agents search from within the incident form to find applicable workarounds
- Contextual suggestions: Agentic AI and ML-based article suggestions surface relevant articles as agents type, dramatically reducing mean time to resolve (MTTR)
How the Modules Connect
Incident → multiple incidents reveal a pattern → Problem
Problem → fix requires a change → Change
Change → successfully resolved → Problem closed → Incidents updated
Knowledge ← every resolved Problem produces a Known Error article
Knowledge → agents reference articles to resolve Incidents fasterThis virtuous cycle — incidents inform problems, problems inform changes, all of them produce knowledge that prevents future incidents — is the operational heartbeat of an ITIL-aligned IT organisation.
Service Level Agreements (SLAs)
Each module integrates with the SLA engine. SLAs define duration targets ("Resolve P1 incidents within 4 business hours") and the engine tracks:
- Response SLA: Time to acknowledge / assign
- Resolution SLA: Time to resolve
SLAs pause during On Hold states, resume on un-hold, and breach when the timer exceeds the target. Breach actions can trigger notifications, escalations, or even change ticket priority.
The Performance Analytics Layer
ServiceNow Performance Analytics layers trend dashboards on top of these modules: MTTR over time, incident volume by category, change success rate, problem resolution velocity. These dashboards are how IT leaders measure operational health.
Try It on Your PDI
- Create an incident; set priority to P2; assign to a service-desk group
- Resolve it referencing a known knowledge article
- Create a problem record and link the incident to it
- From the problem, create a change request for the fix
- Walk the change through the standard workflow and close it
- Confirm the linked problem and incident close automatically
This end-to-end exercise is one of the most common CSA exam scenario questions.