ServiceNow Incident, Problem and Change Roles

Incident, problem and change are the three ITSM processes every ServiceNow interview touches, and the question is rarely “define incident”. It’s usually a scenario: “the payroll portal is down for the third time this month; which records do you create and who owns what?” Candidates who blur the three (closing the problem when service is back, or raising a change to restart a server mid-outage without asking whether policy allows it) lose points. Each record answers a different question, and they work best when linked.

Three questions, three records

• Incident: Is the service working for the user again? An incident is an unplanned interruption or degradation. Success means restoring service as quickly as possible, and a workaround counts. Incidents move through states such as New, In Progress, On Hold, Resolved and Closed.
• Problem: Why does this keep happening, and how do we stop it? A problem is the unknown underlying cause of one or more incidents. Success means finding the root cause and getting it removed, or deciding consciously to live with it. Problem records move through New, Assess, Root Cause Analysis, Fix in Progress, Resolved and Closed.
• Change: Is this modification to production authorised, planned and reversible? A change request governs adding, modifying or removing anything that could affect services. Success means the change is implemented as planned without causing incidents. Normal changes move through New, Assess, Authorize, Scheduled, Implement, Review and Closed.

All three tables extend task, so they share assignment, state, work notes and SLAs, but they carry different fields and are owned by different people. The incident belongs to the service desk or resolver group fighting the fire, the problem to a problem manager or the owning technical team, and the change to its requester, with approval from a change manager or CAB.

One outage, start to finish

Here is a realistic walkthrough. The details are invented for illustration, but the record flow is how the processes fit together on the platform.

Monday 09:10. Users can’t load the payroll portal. The service desk receives 45 calls and chats. Rather than 45 unrelated tickets, one incident (INC0012001) becomes the parent and the rest are linked as child incidents, so updates and resolution flow to every caller. Because payroll runs that afternoon, it’s declared a major incident.

09:35. The application team finds the application server’s database connection pool exhausted. Restarting the application service restores the portal. That restart is a workaround, not a fix, and whether it needs its own change record depends on the organisation’s policy: many treat routine restarts as a pre-approved standard change, others allow restoration actions under the incident and record them in the work notes. What matters is that the decision follows a known policy rather than being improvised.

09:55. Service is confirmed working by users. INC0012001 is resolved with a resolution note describing the restart. The incident did its job: restoration in 45 minutes.

10:30. The problem manager notices two earlier incidents this month with the same symptom. Problem PRB0004012 is opened and all three parent incidents are linked to it through the incident’s Problem field (problem_id). The workaround (“restart the application service; takes 5 minutes”) is documented on the problem, and because the cause isn’t fixed yet but a workaround exists, the problem can be marked as a known error and published as a known error article so the service desk can apply it immediately next time.

Wednesday. Root cause analysis finds that a database driver upgrade three weeks ago leaks connections when reports time out. The upgrade was CHG0030988. The incidents are updated with Caused by Change (caused_by), which is how change-related incidents get counted later.

Thursday. The fix (a driver patch and a timeout setting) is raised as a normal change, CHG0031021, linked from the problem. It goes through risk assessment, a test plan, an implementation plan and a backout plan, is authorised, and is scheduled for Saturday’s maintenance window. If the leak had been causing outages every hour, an emergency change with expedited approval would be the right route instead.

Saturday. The change is implemented and reviewed. The problem moves to Resolved, but it isn’t closed until monitoring shows no recurrence for an agreed period, say two weeks of month-end load. Closing it on Saturday would be the classic mistake: the fix is unproven until the conditions that caused the failure have recurred.

Choosing the right change type

ServiceNow change management distinguishes three types, and interviewers like to probe the boundaries:

• Standard changes are low-risk, repeatable and pre-approved through a template in the standard change catalog, for example adding disk space within limits. They skip CAB because the risk was assessed once, when the template was approved.
• Normal changes go through assessment and authorisation proportionate to their risk.
• Emergency changes exist for fixes that can’t wait for the normal cycle, usually to resolve or prevent a major incident. They still need authorisation (often from a smaller emergency group) and a review afterwards. “Emergency” doesn’t mean “unrecorded”.

Misconceptions worth avoiding

• “The problem is just a big incident.” A major incident is still an incident: its goal is restoration. The problem is a separate record with a separate owner and a longer horizon.
• “Resolve the problem when the incident is resolved.” Service restoration says nothing about the cause. Problems often stay open for weeks.
• “Every incident needs a problem.” Problems are for recurring or significant issues where understanding the cause is worth the effort. One-off incidents with an obvious cause don’t need one.
• “A change record is paperwork after the fact.” The value of change management is the review before implementation, and the link back when a change causes an incident.

Linking records makes the processes measurable

The links are what turn three processes into one system. With problem_id populated you can see which problems generate the most incidents. With caused_by populated you can measure how many incidents changes cause, a key indicator of change quality. An illustrative GlideAggregate count of change-caused incidents over the last 90 days (not run on an instance):

var agg = new GlideAggregate('incident');
agg.addEncodedQuery('opened_at>=javascript:gs.daysAgoStart(90)^caused_byISNOTEMPTY');
agg.groupBy('caused_by');
agg.addAggregate('COUNT');
agg.query();
while (agg.next()) {
    gs.info(agg.caused_by.getDisplayValue() + ': ' + agg.getAggregate('COUNT') + ' incidents');
}

If that list is empty in an organisation that clearly has change-related outages, the field isn’t being filled in, and the change process is flying blind.

Interview practice

Classify each situation and say which record or records you’d create:

1. A user can’t print; the desk reinstalls the driver and it works.
2. The same VPN gateway drops connections every Friday afternoon.
3. The network team wants to upgrade core switch firmware next month.
4. A storage array is failing and will lose data within hours unless a controller is replaced tonight.

Answer

1. An incident, resolved by reinstalling the driver. No problem record unless it recurs across users, which would suggest a common cause such as a bad driver package.
2. Incidents for each occurrence, plus a problem. The recurring pattern is the signal. The problem owns the investigation (Friday load, a scheduled job, a licence limit), documents any workaround as a known error, and leads to a change once the fix is known.
3. A normal change. It’s planned, it affects a critical service, and it needs risk assessment, a maintenance window, testing and a backout plan. No incident or problem exists unless the upgrade is itself the fix for one.
4. An emergency change, almost certainly alongside an incident (the service is degraded or at risk). The change still needs expedited authorisation and a post-implementation review. If the array failure looks like part of a pattern, a problem record follows.

The reasoning to say out loud: incidents restore, problems explain and prevent, changes authorise modifications, and the type of change follows from risk and urgency, not from how busy the team is.

Related reading

• ServiceNow interview questions
• ServiceNow multiple-choice questions
• ServiceNow CMDB Identification and Data Quality, since change impact analysis is only as good as the CIs behind it
• ServiceNow Approvals and Decision Traceability, for change authorisation done properly
• Problem Management (ServiceNow documentation)