Inside a ServiceNow Incident: From First Alert to Closed Ticket
8:47 AM, VPN Down
A monitoring alert fires. Forty employees can't reach the corporate VPN, and the first person to notice is a sales rep on a client call, not the network team. She opens the self-service portal and logs it. That single form submission is the start of everything a ServiceNow ITSM admin actually does day to day, and it's worth following where it goes.
What Gets Created, and What Doesn't
Logging that outage creates an Incident record, not a Problem record and not a Change request, three different tables that beginners mix up constantly. An Incident is "something is broken right now, restore service." A Problem is "why does this keep breaking, find the root cause." It's often opened afterward, once the incident itself is closed. A Change is "we're about to modify something on purpose," which is a different approval chain entirely. Conflating these three is one of the fastest ways to fail a CSA-style scenario question, because the platform genuinely tracks them as separate objects with separate state models, and the exam leans on that distinction hard.
The incident itself moves through a small number of states: New, In Progress, On Hold, Resolved, Closed. Each transition can be logged, timed, and reported on, which is the entire point of running ITSM on a platform instead of an inbox.
The Matrix That Decides Everything Next
Before anyone gets assigned, the incident needs a priority, and priority isn't typed in freehand. It's calculated from two fields: Impact (how much of the business this affects) and Urgency (how fast it needs fixing). A VPN outage blocking forty people is high impact and high urgency, which lands it as a P1.
- High impact, high urgency
- page the on-call engineer
- VPN outage blocking dozens of staff fits here
- High impact or high urgency, not both
- a single department locked out of one app
- Localized, workaround usually exists
- one user's printer driver crashing
- Cosmetic or single-user, no workflow blocked
- a UI label is wrong
Those response windows aren't a ServiceNow default so much as the kind of target a team sets in its own SLA definitions inside the platform, using exactly the Impact/Urgency fields above. Get the matrix wrong at intake and everything downstream inherits the mistake: the wrong assignment group gets paged, the SLA clock counts down against the wrong deadline, and a genuine P1 can sit quietly behind three P3s in someone's queue.
From Logged to Resolved
- 1
Log It
Caller or self-service portal creates the record with a short description
- 2
Categorize
Impact and Urgency set the Priority automatically
- 3
Assign
Routed to a group by category, e.g. Network Ops for VPN issues
- 4
Diagnose
Assigned tech works it, adding Work Notes as they go
- 5
Resolve
Root fix applied, a resolution code recorded, not just "fixed"
- 6
Close
Confirmed with the caller, then locked; reopens create a new record
That "Work Notes" field in step four trips up almost everyone new to the platform. It's internal-only, visible to IT staff. "Additional Comments" is the field the caller actually sees. Type troubleshooting detail into the wrong one and either the customer gets a wall of jargon or the next tech inherits a ticket with nothing useful written down.
The Same Engine Runs Requests, Not Just Outages
Incidents get the attention, but a large share of what an ITSM admin actually builds is Service Catalog items: "request a new laptop," "reset my VPN access," things a user asks for rather than something breaking. These don't skip the approval step the way an incident does.
Flow Designer is what actually builds that approval gate, no scripting required for the common cases, which is why the platform's own automation module teaches it before anything code-based. The gate itself is just a workflow definition sitting on top of the same state-and-assignment machinery that ran the VPN incident above.
A Habit Worth Building Early
One thing that separates a tidy ServiceNow instance from a messy one, and it's rarely covered in intro material: close every incident with an actual resolution code, not a generic "resolved" with no detail. Six months later, when someone runs a report asking "why do VPN incidents keep happening," a queue full of undocumented closures makes that question unanswerable. A queue with real resolution codes turns into the Problem-management input that catches the pattern before it becomes a tenth outage.
Try It on a Real Instance
Reading the state model is one thing. Watching a P1 actually route, escalate, and breach its SLA clock on a live instance is what makes the CSA-style scenario questions click. SkyTrainings' ServiceNow ITSM course runs on an actual ServiceNow instance rather than slides, covering incident, problem, and change management alongside catalog builder and Flow Designer.
