SERVICENOW ITSM
INTERVIEW Q&A.

Walk through the Incident state model.

New → In Progress → On Hold → Resolved → Closed, with Canceled as a terminal side-branch. Resolved requires close_code + close_notes; Closed is set by a scheduled job (default 7 days after resolution).

• State field is `incident_state` (integer). Values: 1 New, 2 In Progress, 3 On Hold, 6 Resolved, 7 Closed, 8 Canceled.
• `On Hold` requires a `hold_reason` (Awaiting Caller, Awaiting Change, Awaiting Problem, Awaiting Vendor).
• Moving to Resolved requires close_code and close_notes — enforced by the 'Incident state' UI Policy + a Business Rule.
• Closed is normally set by the 'Incidents auto-close' scheduled job. Users cannot re-open a Closed incident; they must create a new one linked via `parent_incident`.

How does Major Incident Management differ from a regular incident?

Priority 1 incidents can be promoted to Major Incident (MI). MI adds a communication workbench, MIM role approval, and posts updates to the MI Board.

• Trigger: incident.priority = 1 AND `promote_to_major` is set; requires role `major_incident_manager` to approve.
• Creates a record in `major_incident` (extends task) and links back via `major_incident_ref` on the source incident.
• Communication Workbench pushes updates to subscribers via email + Now Mobile push. Timeline is on `major_incident_communication`.
• After resolution the Post Incident Report (PIR) triggers a Problem record automatically if `create_problem_on_close` is true.

Explain the incident assignment flow.

Assignment group first (via Assignment Rules or predictive intelligence), then assigned_to via on-call schedule or round-robin business rule.

• `sys_assignment_rule` matches conditions in order and stamps `assignment_group`.
• Predictive Intelligence (Agent Intelligence) can override using a trained classifier on short_description.
• `assigned_to` typically empty at creation; picked up via On-Call Scheduling (cmn_rota_member) or a scripted rotation.
• Reassignment resets `reassignment_count` and can breach the assignment SLA if it happens after the response target.

Problem vs Incident — how are they linked?

An incident is a single service disruption; a problem is the underlying cause. Link incidents to a problem via `problem_id` on incident; the problem tracks all related incidents through `rel_ci` and its own worknotes.

• Table: `problem` extends `task`. Related list on incident shows all incidents sharing the same `problem_id`.
• Resolving the problem does not auto-resolve incidents — a Flow Designer subflow (or business rule) is required to close children.
• 'Duplicate incident' pattern: set `duplicate_of` on child incidents so reporting rolls them up under the primary.

Walk through the Problem state model.

New → Assess → Root Cause Analysis → Fix in Progress → Resolved → Closed. Known Error is a flag (`known_error` = true), not a state.

• Fields: `problem_state` (1..108). RCA requires `cause_notes`; Fix in Progress usually creates a Change (`fix_change`).
• 'Known Error' is set when a workaround exists (`workaround` populated). This makes the problem selectable from incidents.
• Closure requires `resolution_code` (Fix Applied, Risk Accepted, Duplicate, Canceled).

What RCA techniques does ServiceNow support natively?

5 Whys, Fishbone, and Kepner-Tregoe are template-driven via `problem_task` records. The Problem Coaching workflow guides analysts step-by-step.

• `problem_task` extends task and is used for RCA sub-activities.
• Templates live in `sys_template` filtered on table = problem_task.
• Predictive Intelligence can cluster similar incidents to surface candidate problems (Similar Incidents pane).

Difference between Standard, Normal, and Emergency change?

Standard = pre-approved template, low risk, no CAB. Normal = full assessment + CAB approval. Emergency = expedited path for outage remediation, retrospective CAB review.

• Standard changes are instantiated from `std_change_producer_version` (a template producer). Approval is skipped because the template was pre-approved.
• Normal changes run through the Change Approval Policy engine (`sn_change_approvals`) — a Flow Designer flow that computes approvers from risk + assignment group + CAB.
• Emergency: `type = emergency` fires a different approval path (ECAB), enforces shorter lead time, and requires a Post Implementation Review (PIR).

// Enforce ECAB approval for Emergency changes (business rule on change_request, before update)
(function executeRule(current, previous) {
  if (current.type == 'emergency' && current.approval == 'approved') {
    var ecab = new GlideRecord('sys_user_grmember');
    ecab.addQuery('group.name', 'ECAB');
    ecab.addQuery('user', gs.getUserID());
    ecab.query();
    if (!ecab.next()) {
      gs.addErrorMessage('Only ECAB members can approve Emergency changes.');
      current.setAbortAction(true);
    }
  }
})(current, previous);

How does risk assessment work?

Risk is computed via a Risk Assessment questionnaire (`asmt_assessment_instance`) that scores answers and writes `risk` + `risk_impact_analysis` back on the change.

• Questionnaire metrics live in `asmt_metric`. Weights per answer accumulate into a decimal score.
• Score → Risk mapping is in the 'Change Risk Conditions' table (`chg_risk_condition`).
• Predictive Intelligence 'Change Success Score' overlays a probability-of-success on top of the static risk.

How does conflict detection prevent overlapping changes?

The Conflict Calculator runs on schedule/update: it checks CI + affected-CI overlap against other changes in the planned window and writes findings into `conflict`.

• Fields on change: `conflict_status` (Not Run / No Conflict / Conflict) and `conflict_last_run`.
• Triggered by: schedule change, CI change, or manual 'Check conflicts' UI action.
• Conflict types: same CI, dependent CI (via cmdb_rel_ci), blackout window, maintenance schedule.

How is an SLA attached to a task?

The SLA Engine evaluates `contract_sla` definitions on insert/update of the task. Matching definitions attach a `task_sla` record and start the timer against the SLA's business schedule.

• Definition table: `contract_sla`. Attachment table: `task_sla` — one per attached SLA per task.
• Timer respects the SLA's Schedule (cmn_schedule) — off-hours don't count toward elapsed time.
• Pause conditions (e.g., `state = On Hold`) freeze the timer without breaching.
• Retroactive start: set the SLA definition's Start Condition to a past field like `opened_at` when the SLA should have already been running.

SLA vs OLA vs Underpinning Contract?

SLA = commitment to the customer. OLA = internal team-to-team agreement. UC = commitment from an external vendor. All three use the same `contract_sla` engine, differentiated by the `type` field.

• SLA fails → customer breach (visible on portal).
• OLA fails → internal breach (reported on team dashboards, feeds into SLA calculation).
• UC breach → vendor accountability; often linked to a Vendor Manager workflow.
• Chained: an SLA can be underpinned by multiple OLAs + UCs — dashboards visualize the dependency chain.

How would you send an alert 30 minutes before SLA breach?

Use an SLA Workflow (attached to the SLA Definition) with a 'Timer' activity set to `business_percentage = 90%`, then a 'Notification' activity.

• Legacy SLA Workflow: Workflow → SLA → drag Timer + Notification. Timer supports business time and % elapsed.
• Flow Designer path (Rome+): trigger = 'SLA task % elapsed', use the SLA Task Notifications action.
• Avoid scheduled scripts polling `task_sla` — the engine already emits events (`sla.breached`, `sla.warning_50`, `sla.warning_75`) you can subscribe to.

// Business rule on task_sla (after update) — custom warning event
(function executeRule(current, previous) {
  if (current.business_percentage >= 90 && previous.business_percentage < 90) {
    gs.eventQueue('sla.warning_90', current, current.task.getDisplayValue(), current.sla.getDisplayValue());
  }
})(current, previous);