OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow incident and problem practice

ServiceNow incident and problem management with a clear response path

ServiceNow incident and problem management should make the operational response visible from impact and ownership through investigation, communication, restoration and follow-up. OBLYTECH helps organisations connect the urgent incident path to the slower work of understanding recurring causes.

Discuss ServiceNow incident and problem-management priorities

Establish impact, ownership and the next decision

Record the affected service or user action, current impact, detection context, incident owner, response groups and next decision. Distinguish assignment from accountability. The person working the technical task may not be the owner who decides what the service audience needs next.

Trace incident work from detection to restoration

Follow evidence from detection through triage, investigation, workaround, change or containment, validation and restoration. Record what is confirmed, what is suspected, what action was attempted and what remains uncertain. Restoration should identify whether permanent correction or follow-up is still required.

Coordinate major-incident communication

Communication should state what is affected, what is being investigated, what users should do and when the next reliable update will arrive. Keep known facts separate from working theories. Adjust the explanation for employees, service owners and decision-makers while retaining one underlying incident record.

Move recurring causes into problem management

When incidents reveal a repeating or unresolved cause, create a problem path with an owner, evidence, affected service, investigation boundary and next decision. A problem record should carry the work needed beyond immediate restoration rather than be a label added at closure.

Close with evidence and remaining work

Closeout should state the confirmed cause when known, restoration or containment action, remaining risk and follow-up with an owner. Review reopened incidents, repeated workarounds, unresolved dependencies and communication gaps. A closed incident can still require a problem, change, monitoring adjustment or knowledge update.

For the operating baseline, see ServiceNow ITSM and Service Operations. For response evidence, review ServiceNow risk assessment and control testing.

Discuss ServiceNow incident and problem-management priorities

Bring one incident path, major-incident communication gap or recurring cause that lacks a clear owner. OBLYTECH can help connect impact, response, evidence, restoration and follow-up.

Start the conversation

When a major incident needs its own coordination path

Many incidents are resolved by the team that receives them, using the normal queue, priority rules and escalation paths. A major incident is different in one specific way: the response starts to depend on people who are not working the fault. Service owners need to know what to tell customers, executives need a decision they can make, and the technical teams need one place where the facts are kept. When those audiences start asking the same questions in separate channels, the organization is in a major incident whether or not the priority field says so.

The design question is therefore when the normal path should hand over to a coordinated one. A useful answer names the conditions rather than a single severity label. Examples include an impact that crosses service boundaries, a restoration that depends on more than one supplier, an uncertain cause that is affecting a regulated process, or a customer-facing outage that will not clear within the expected window. The conditions should be written so that an on-call engineer can apply them at two in the morning without a conference call.

ConditionNormal incident pathCoordinated major incident path
Impact sits inside one service and one teamOwned by the assignment group, updated in the recordNot needed unless the restoration time is uncertain
Impact crosses services or customer groupsOwner keeps working, with a manual status noteA single incident commander, a bridge and a shared facts log
Restoration depends on a supplier or another internal teamDependency logged, no named decision-makerDependency owner present, with a decision time agreed
Cause is unknown and the affected process is regulatedInvestigation continues in the queueInvestigation and evidence preservation run as separate tasks

The table is a starting point for a conversation with service owners, not a finished policy. The thresholds should be set with the people who carry the business consequence of an outage, and they should be reviewed after the first few real events, since those events tend to show which condition was missing.

What the first ten minutes of a response should produce

The first minutes of an incident decide whether the rest of the response is organized. Teams that start investigating before they have stated the impact often spend the next hour correcting the scope. A short, fixed set of outputs for the first stage helps the response start on the right footing: the affected service and user action, the time the impact began, the person who owns the incident, the groups engaged, and the next decision with a time for it.

Separating assignment from accountability matters here. The engineer who restarts a service may be the best person to test a hypothesis, but the owner is the person who decides whether the team wait for that test or move to a workaround. When the owner is unclear, the response tends to stall while each group assumes another group is deciding.

  • State the affected user action in plain words, not as a system name.
  • Record the detection source, whether an alert, a user report or a monitoring threshold, because it shapes how confident the team should be.
  • Name the incident owner and the response groups separately.
  • Set the next decision point, even if the decision is only whether to continue investigating for another interval.

How investigation, workaround and restoration differ in the record

Restoration and root cause are different achievements, and the record should show which one has been reached. A workaround restores the service enough for users to continue, while the cause may still be unknown or may require a change that will be made later. Recording a restoration as if it were a fix can create the repeat incidents that problem management is meant to prevent.

A practical way to keep this clear is to label each action in the timeline as one of four types: a hypothesis being tested, an action taken, an evidence item collected, or a state change confirmed by monitoring. The team can then read the timeline and see which statements are confirmed. This also helps the post-incident discussion, because it separates what the team knew at each point from what it learned afterwards.

Communication that different audiences can use

A major incident produces at least three audiences with different needs. Employees need to know what they can do now. Service owners need to know what the business impact is and when the next update will come. Executives need to know whether a decision is required from them. A single status message rarely serves all three, so the response should keep one incident record and derive shorter statements from it for each audience.

The most common communication failure is an update that mixes confirmed facts with working theories. A sentence such as the fault appears to be in the storage layer may be a reasonable hypothesis, but if it is published as a fact it will shape decisions and expectations. Separating what is known from what is suspected, and stating when the next update will arrive whether or not the situation has changed, keeps trust while the response continues.

Moving from a restored service to a recurring cause

Problem management begins when an incident reveals a cause that will return unless someone owns it. The difficult part is the hand-off. The incident team is focused on restoration and has little time to write up the evidence. The problem team needs that evidence to decide whether the cause is worth investigating, and often receives an incident record that describes what happened but not what was checked.

A problem record should therefore be opened with an owner, the affected service, the evidence already collected, the investigation boundary and a decision date. The problem record guide describes what a problem record is and how it links to incidents. Without those elements, a problem becomes a label added at closure, and the same cause returns under a different incident number.

Closeout itemMinimum contentCommon gap
Confirmed causeThe cause if it is known, or a statement that it is not yet knownHypothesis recorded as confirmed
Restoration actionWhat was done, by whom, and whether it is permanentWorkaround recorded as a fix
Remaining riskWhat could recur and under which conditionsNo statement at all
Follow-upProblem, change or monitoring action with an ownerFollow-up listed without a named owner

Reviewing response quality without blaming individuals

A review after a major incident is useful when it looks at the conditions that made the response hard, not at the people who were working through them. The questions that tend to produce the most useful findings are these: at what point did the owner become unclear, which decision waited longer than it should, which update was late, and which evidence was lost because nobody was assigned to preserve it. Each answer points to a change in design, a training need or a missing role.

Reopened incidents deserve particular attention. An incident that reopens within a short period often indicates that restoration was not validated against the user action. Repeated workarounds across different incidents show that a problem record should exist even if the cause is not yet clear.

Does every priority one incident need a major incident process?

Not necessarily. A priority one incident confined to one team with a known restoration path may be handled in the normal queue. The coordinated path is for conditions that create coordination needs, such as cross-service impact, supplier dependency or an uncertain cause in a regulated process.

Who should act as the incident commander?

The role should go to someone who can make or escalate decisions and is not also doing the deepest technical work. The commander’s job is to keep the facts log current, hold the decision timetable and make sure each audience receives the right update.

Should the problem record be opened during the incident?

If the cause is already suspected to be systemic, yes. Opening it early with a named owner and a clear boundary helps prevent the investigation from being dropped when the service returns to normal.

How long should evidence be kept after restoration?

Long enough for the problem owner to examine it. The retention period should follow the organization’s own evidence and records rules, and the incident record should say where the evidence is held and who can release it.

Next step for incident and problem coordination

If a recent outage was harder to coordinate than it should have been, the most useful next step is a walkthrough of that single event. Such a walkthrough would use the timeline, the messages that went to each audience and the problem record that was or was not opened afterwards. That evidence is enough to decide where the coordination path should begin. For the detection side of the same response, the event management and alert correlation page describes classifying alerts, relating them to service impact and connecting them to an owner. The runbook automation and remediation page describes choosing repeatable operational actions with guardrails, and the observability and resilience page describes connecting signals to service context, ownership and response boundaries. The incident priority guide explains what incident priority means and where it sits on the incident record.

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

Related guides

More in this section