The ITSM round is the process round, and it usually follows the platform and scripting screen. It carries weight because most work on a live ServiceNow project is incident, problem, change and SLA work rather than scripting. The questions below come from the RizeX Labs question bank, grouped the way a panel moves through them: change management first, then incident, problem, knowledge and service level management. Answers stay at process level with the ServiceNow records named, because that is the combination an interviewer listens for.
Change Management
What are the different types of change in ServiceNow?
Three ship out of the box on the change_request table. The type decides which state flow the record follows, who approves it, and how much notice it needs.
| Change type | Approval requirement | Lead time | Used for |
|---|---|---|---|
| Standard | Pre-approved as a procedure, none on the record | None or very short | Low risk repeatable work from a template |
| Normal | Assessment plus CAB authorisation | Days, set by change policy | Real risk, not routine, not urgent |
| Emergency | Expedited approval by the emergency CAB | Hours or less | Restoring a failed service |
What is a standard change?
A low risk repeatable change assessed and approved once, as a procedure. It is raised from a standard change template that pre-fills the implementation, test and backout plans, and because the procedure carries the approval the record skips assess and authorise.
What is an emergency change?
A change raised to restore a service that is already broken or stop a failure about to happen. It uses a shortened state flow and is authorised by the emergency CAB, with documentation and the review completed afterwards.
Difference between standard, normal and emergency change?
The table above covers the mechanics. The decision rule is what gets asked: risk and repeatability decide standard against normal, urgency decides normal against emergency. A high risk change does not become an emergency because somebody left it late.
Explain the change management lifecycle?
For a normal change the state model runs New, Assess, Authorise, Scheduled, Implement, Review, Closed, with Cancelled as an exit.
- New. Requester logs it, names the affected CI, writes the implementation, test and backout plans.
- Assess. Risk and impact are judged, and risk assessment questions can calculate the risk field rather than someone typing it.
- Authorise. Approvals generate and the CAB reviews.
- Scheduled. Planned start and end are set, and conflict detection runs against blackout windows, maintenance schedules and other changes on the same CI.
- Implement. Work happens inside the approved window.
- Review. The post implementation review records the outcome.
- Closed. Close code and close notes are set.
Standard changes skip assess and authorise. Emergency changes compress assess into authorise.
What is CAB?
The Change Advisory Board, the group that authorises normal changes. In ServiceNow it is configuration rather than a calendar invite: you define the board, generate meetings on a schedule, build the agenda from changes awaiting authorisation, and run it from the CAB Workbench, where each vote writes back to the approval record.
What is change approval policy?
The rule set deciding who must approve a given change. Rather than hard coding approvers, you define policies with conditions on type, risk, category or affected service, so a low risk change may need only the group manager while a high risk one pulls in the service owner and the full CAB.
What is lead time in change management?
The minimum notice between a change being raised or approved and its planned start. A normal change with a five day lead time cannot start tomorrow, and the rule is enforced through change policy validation rather than goodwill.
What is blackout window?
A defined period when changes must not be implemented on a CI, a service or the whole estate, such as year end or a payroll run. It is configured as a schedule referenced by change management, and conflict detection warns when a planned window falls inside it.
A maintenance window says when change is allowed. A blackout window says when it is forbidden. Candidates confuse the two often enough that panels ask on purpose.
What is affected CI?
A configuration item the change will touch, recorded on the Affected CIs related list. It drives conflict detection on that CI, the impacted services calculation that walks CMDB relationships, and the risk score. A change with no affected CI is a change nobody can assess.
How do you create a new type of change?
You build a change model: define its states and transitions, set the condition on each transition, attach the change policy that generates approvals, and expose it to requesters. Projects need one when a flow requires an extra state, such as vendor dispatch or a DBA sign off.
What is PIR (Post Implementation Review)?
The review done in the Review state. It records whether the change achieved its aim, whether it caused incidents, whether it finished inside its window, and whether the backout plan was used, and its output feeds problem management and the change policy.
Difference between change and request?
A change alters a configuration item or service under a controlled process and lives on change_request. A request is a demand for something already published in the service catalogue, fulfilled without altering the service. Asking for a laptop is a request, upgrading the operating system across the estate is a change.
What the interviewer is actually checking
- Whether you can place a scenario into the right change type and defend the choice.
- Whether lead time, blackout windows and conflict detection are configuration to you, not documents in a shared drive.
- Whether affected CI means anything beyond a field name.
- Whether you have watched a change move through its states or only read the state list.
Incident Management
What are OOB incident fields?
Number, caller, contact type, business service, service offering, configuration item, category, subcategory, impact, urgency, priority, state, on hold reason, assignment group, assigned to, short description, description, and on closure the resolution code and close notes.
Do not just list them. Say which ones drive behaviour: impact and urgency calculate priority, category drives assignment, state and on hold reason drive the SLA timer.
What is service offering on incident form?
A business service is the service as the business names it, for example Email. A service offering is a specific commitment level of it, such as Email Gold at 24x7 against Email Standard at business hours, which lets one service carry different SLA targets and support groups.
What is incident categorization?
Classification through category and subcategory, alongside the affected service and CI. It routes the ticket, makes reporting meaningful, and lets problem management spot clusters. Poor categorisation shows up months later as a report nobody trusts.
What is major incident management?
The separate, faster process for incidents with severe business impact. An incident is flagged as a major incident candidate, the major incident manager accepts or rejects it, and on acceptance the workflow adds a communication plan, a war room and stakeholder updates on a fixed cadence.
Difference between incident and major incident?
A normal incident is any unplanned interruption, owned by the assignment group and measured on restoration time. A major incident hits a critical service or a large user base, and it adds a major incident manager above the resolver groups, a promotion step through candidate and accepted states, and a formal timeline review that usually raises a problem.
How do you automate incident assignment?
- Assignment rules, matching on conditions to set group or assignee.
- Data lookup rules, deriving group, impact or urgency from a lookup table instead of scripted logic.
- Flow Designer, when assignment needs a sequence of steps or a call to another system.
- Predictive Intelligence, training a model on closed incidents to predict the group from the short description.
Include the fallback. Whatever you automate, a default group has to catch what the rules miss, or tickets sit unassigned.
What KPIs are important for incident management?
- MTTR, meaningless without a priority breakdown behind it.
- Response time, and often this is the SLA that actually breaches.
- First contact resolution, which measures whether knowledge management works.
- SLA compliance, tied directly to contractual penalties.
- Reassignment count, where high values mean bad categorisation or unclear ownership.
- Reopen rate, which exposes premature closure done to protect MTTR.
- Backlog and ageing, showing where the queue is quietly rotting.
Say you reported on these and the panel will ask which one your project was failing and what you changed. Memorised definitions collapse the moment a question turns into a real project example, and KPIs are where that happens most.
What the interviewer is actually checking
- Whether you can connect impact and urgency to priority to SLA target as one chain.
- Whether service offering means something beyond a duplicate of business service.
- Whether you know automated assignment needs a fallback group.
- Whether your KPI answer has a real problem behind it.
Problem Management
What is a problem?
The cause, or suspected cause, of one or more incidents. The incident restores service, the problem removes the reason service broke. A single incident can justify a problem when the cause is unknown and likely to recur.
Explain problem management lifecycle?
The state model runs New, Assess, Root Cause Analysis, Fix in Progress, Resolved, Closed.
- New. Logged with the related incidents attached.
- Assess. Qualified and prioritised, because not every problem is worth investigating.
- Root Cause Analysis. The investigation runs, and a workaround is usually published here, well before any fix exists.
- Fix in Progress. The permanent fix is built, and if it touches a CI it is delivered through a change.
- Resolved. Fix in place, resolution recorded.
- Closed. Related incidents closed and the knowledge article published.
What is root cause analysis?
The structured investigation establishing why the failure happened, not just what failed, using five whys, fishbone or timeline reconstruction from logs and change history, with the output recorded in the cause and fix notes.
The weakness is stopping at the symptom. "The service ran out of memory" is not a root cause. "A change removed the log rotation job, the disk filled, and the service could not write" is.
Difference between reactive and proactive problem management?
Reactive starts from incidents that already happened and works back to the cause. Proactive starts from trend data, monitoring, failed changes and near misses. Most projects do reactive well and proactive badly, because proactive needs an owner with no ticket forcing them to act.
What is known error?
A problem whose root cause is understood, or which has a workaround, documented so support teams can act immediately. These records form the known error database, and the point is speed: the next matching incident gets the workaround in minutes.
How is a workaround defined?
A documented way to restore service or reduce impact without fixing the cause. It is recorded in the workaround field on the problem and can be communicated to every linked incident, so the service desk sees it on the ticket. One still in place a year later is a failure, not a success.
Relationship between incident, problem, and change?
| Incident | Problem | Change | |
|---|---|---|---|
| Purpose | Restore service now | Remove the cause | Deliver the fix safely |
| Trigger | A reported failure | Recurring incidents or analysis | An approved fix or planned work |
| Measured by | Speed of restoration | Fewer repeat incidents | Success rate |
| Output | Resolution or workaround | Root cause and known error | Implemented change and a PIR |
Panels like this chain because it is easy to test. Four hundred users cannot log in, incidents are raised, a restart restores service. A problem opens, RCA finds a certificate expiry with no renewal alert, a known error and workaround are published, a normal change adds renewal automation, and after the PIR the problem closes.
What the interviewer is actually checking
- Whether you can separate cause from symptom when pushed on a root cause.
- Whether you know a workaround lives on the problem and reaches incidents from there.
- Whether you can narrate one incident to problem to change chain without losing the thread.
Knowledge Management
What is Knowledge Management?
The process of capturing, reviewing, publishing and retiring the articles that let agents and end users resolve issues without raising or escalating a ticket. It runs on knowledge bases, categories and articles, with ownership and review cycles on each article.
Knowledge article lifecycle?
Draft, Review, Published, Retired. The author writes into a knowledge base and category, approvers assess accuracy, and the publish approval can be workflow driven or switched off for a low risk base. Once published the article is visible to whoever the user criteria allow and searchable from the portal and the incident form. Articles are versioned, so a published one can be checked out, edited and republished, and retirement should be triggered by a scheduled review date rather than someone noticing.
Difference between internal and external knowledge?
Internal knowledge is for support staff and holds detail that must not leave the organisation: server names, escalation contacts, diagnostic steps. External knowledge is for end users or customers, in their language. Most projects separate them into different knowledge bases rather than controlling it article by article.
How do you control knowledge visibility?
Through user criteria. You define criteria records based on role, group, department, company or location, and apply them at knowledge base level as can read, cannot read, can contribute and cannot contribute, with can read and cannot read also available on individual articles. Cannot read wins over can read, and that is the detail candidates get wrong.
Service Level Management
What is SLA?
A recorded commitment on how quickly a task must be responded to or resolved, agreed between provider and customer. It lives in an SLA definition holding the target duration, the schedule the clock runs on, and the start, pause and stop conditions, and a matching task attaches a task SLA record that tracks the timer.
What is OLA?
An operational level agreement, a commitment between internal teams that supports the customer facing SLA. If the customer SLA promises four hour resolution, the database team may hold a ninety minute OLA for their part. It is configured in the same place as an SLA with the type field set to OLA.
Difference between SLA, OLA, and UC?
| SLA | OLA | UC | |
|---|---|---|---|
| Parties | Provider and customer | Two internal teams | Provider and external vendor |
| Binding | Usually contractual | Internal commitment | A commercial contract |
| Purpose | What the customer is promised | Teams can deliver that promise | Suppliers deliver their part |
| In ServiceNow | Type set to SLA | Type set to OLA | Type set to Underpinning Contract |
All three are agreement records with the same fields, separated by the type. OLA and UC targets must be tighter than the SLA they support, otherwise the SLA cannot be met even when every team performs.
What is SLA workflow?
The automation attached to an SLA definition that runs against the task SLA timer and fires actions at set percentages of elapsed time: notify the assigned user at 50 percent, the group manager at 75, escalate and record the breach at 100. Projects normally clone the default workflow to change those points.
What is SLA breach?
When elapsed time passes the target duration before the stop condition is met. The task SLA is flagged as breached, its stage changes, and elapsed time keeps running so you can report how badly it was missed. Pause conditions matter: an incident on hold awaiting caller information usually pauses the clock.
How SLA priority is calculated?
Priority is not typed in. It is derived from impact and urgency through the priority lookup rules, and the SLA definition then conditions on that priority.
| Impact / Urgency | 1 High | 2 Medium | 3 Low |
|---|---|---|---|
| 1 High | 1 Critical | 2 High | 3 Moderate |
| 2 Medium | 2 High | 3 Moderate | 4 Low |
| 3 Low | 3 Moderate | 4 Low | 5 Planning |
Impact is how much of the business is affected, urgency is how fast it needs attention. One user with a dead laptop is low impact and high urgency. A slow report across finance is high impact and lower urgency. Changing the matrix means changing the lookup rules, not scripting the priority field.
Difference between task SLA and SLA definition?
The definition is the template, configured once, holding the target duration, schedule, type and the start, pause and stop conditions. The task SLA is the running instance created when a task matches, holding start time, elapsed time, percentage complete, stage and breach flag.
When a panel asks why an SLA is not appearing on a ticket, they want you to debug: is the definition active, did the start condition match at save time, does the task SLA record exist. That separates people who have used SLAs from people who have read about them.
What the interviewer is actually checking
- Whether you can name the right agreement type for a vendor, an internal team and a customer.
- Whether you know priority is calculated rather than chosen.
- Whether pause conditions and schedules sit inside your model of an SLA timer.
- Whether you can debug a missing SLA, which tests far more than defining one.
Closing
Most candidates lose this round on delivery, not knowledge. They know what a blackout window is and then cannot say where it was configured on their project or which release it stopped. Answer in the same shape every time: the situation, the approach you took, the reason you chose it, the result.
Work through these questions by writing one real example against each, from a project you can defend at five levels of depth. For structured practice on the ITSM modules with instructor review, the ServiceNow training programme at RizeX Labs covers incident, problem, change and SLA configuration hands on, with mock rounds on this question set.