ITSM & Operations

Normal — full lifecycle with assessment and CAB approval; the default for anything with real risk. Standard — pre-approved, low-risk, repeatable changes executed from a template in the standard change catalog (e.g. routine patching). Emergency — expedited path for urgent fixes, approved by an emergency CAB, often documented after the fact.

New → Assess (risk/impact analysis, peer review) → Authorize (CAB approval) → Scheduled (planned window) → Implement (work + change tasks) → Review (post-implementation review) → Closed. Know which approvals gate which transitions and where risk assessment happens on your project.

A request is fulfillment of something standard from the catalog — no alteration to CI/service behavior (new laptop, access grant). A change modifies the state or configuration of production infrastructure or services and carries risk needing assessment. Litmus test: could it break something for other users? Change.

The Change Advisory Board — the group that reviews, prioritizes and approves changes, weighing risk, collision and scheduling. ServiceNow supports it with CAB Workbench: agenda building, meeting management and decision recording tied to the change records.

The unknown underlying cause of one or more incidents. Incident management restores service; problem management finds root cause and eliminates recurrence — via known errors, workarounds and fixes delivered through change.

New → Assess → Root Cause Analysis (with a documented workaround published to linked incidents as early as possible) → Fix in Progress (usually via a change) → Resolved → Closed. Known Error is the state where cause is known but the permanent fix isn't yet deployed.

Twenty users raise incidents: "email is slow" (restore service — restart the service, incidents resolved). A problem is opened to find why it keeps happening; RCA finds a memory leak in a mail server component. The fix requires a patch to production — a change is raised, approved and implemented. Change closes → problem closes → recurrence stops. Incidents treat symptoms; problems find causes; changes deliver cures.

Two outcome buckets: speed (MTTR, first-response time, SLA compliance %) and quality (first-call resolution rate, reopen rate, reassignment count, backlog age). Reassignment count and reopen rate are the underrated ones interviewers like — they expose routing and resolution quality problems that MTTR hides.

A Service Offering is a defined level/flavor of a business service (e.g. "Email — Gold" with specific hours and commitments); on the incident it sharpens what exactly was impacted. An OLA (Operational Level Agreement) is an internal back-to-back commitment between support teams that underpins the customer-facing SLA — in the platform, OLAs are just SLA definitions of type OLA.

Via knowledge-centered service (KCS): check "Knowledge" on the incident at resolution, or use the Create Knowledge UI action — the platform drafts an article from short description and resolution notes into the selected knowledge base, where it goes through that KB's approval workflow before publishing.

A change model defines a change's lifecycle: its states, transitions, required approvals and policies (Normal/Standard/Emergency are OOB models; you can build your own). The change interceptor is just the routing page shown when a user clicks Create New — it asks questions and directs them to the right model/template. Model = lifecycle definition; interceptor = front door.

The gate where required approvals happen — CAB or delegated approvers assess risk, schedule conflicts and readiness. The change cannot move to Scheduled/Implement until approvals complete; rejection sends it back for rework or cancellation.

A solid structure: gather requirements (categories, priorities, assignment rules, SLAs, notifications) → configure foundation data (groups, schedules, locations) → configure the module (forms, states, assignment via predictive/assignment rules, SLA definitions, notifications) → integrations (monitooring/event sources, email) → UAT → hypercare. Real challenges to cite: category sprawl, agreeing the priority matrix across business units, assignment rule conflicts, and email loop issues with inbound actions.

In the record producer script (or a flow triggered by the produced record), insert the extra records after the primary one is created — producer variables are available in the script. For catalog items proper, the item's flow/workflow creates the additional catalog tasks.

Foundation first: users/groups/roles (LDAP/SSO), locations, schedules, companies. Then process by process — incident, request, change, problem — each through workshops → configuration → data migration → integration → testing → training → go-live. The practical wisdom interviewers reward: resist customization in wave one, keep OOB where possible, and get foundation data right because everything else references it.

The minimum notice between raising/approving a change and its planned start — e.g. "normal changes need 5 business days." It gives CAB and impacted teams assessment time. Enforced via change policies or validation on planned start date; emergency changes exist precisely to bypass it under control.

Priority tiers derived from impact × urgency: P1 critical — major outage, all-hands, tightest SLA; P2 high — significant degradation or a whole team blocked; P3 moderate — limited impact, workaround exists; P4 low — minor issues and questions. Each tier maps to response/resolution SLA targets and escalation behavior.

Both are schedule records evaluated against the change's planned dates. A blackout window is when changes must NOT happen (year-end freeze, big launch). A maintenance window is when changes SHOULD happen (Sunday 2–6 AM). Conflict detection flags a change whose window violates either.

Push back first: pre-approval is the defining property of a standard change — adding approval makes it a normal change in disguise. The approval belongs on the template proposal (approving that this change type is safe to repeat), not on each execution. If they insist on a lightweight check, implement it via the change model's policy, but document that it deviates from ITIL intent.

The "Affected CIs" related list (task_ci) records every configuration item impacted by an incident/change/problem — beyond the single primary cmdb_ci field. It feeds impact analysis, collision detection between changes, and service maps of what's at risk during a window.

Create a new change model: define its states, transitions, approval policies and templates, then expose it through the Create New flow/interceptor. Pre-model platforms did this with a new choice value on change_request.type plus conditioned workflows — worth mentioning you know both eras.

Technically much of it, but the right tools are change models, approval policies, flows and the state model — declarative, upgrade-safe, visible to process owners. Scripted state machines in BRs become unmaintainable and fight platform upgrades. Knowing what not to script is a senior signal.

An unplanned interruption to, or degradation of, an IT service. Examples: email down, VPN failing for a region, an application error blocking checkout, a printer offline. Not incidents: asking for new software (request) or a recurring cause under investigation (problem).

Restore normal service operation as quickly as possible and minimize business impact — not to find root cause. Workarounds are legitimate resolutions; the "why" belongs to Problem Management.

A major incident is one with severe, wide business impact that triggers a dedicated process — major incident manager, comms cadence, war room (Major Incident Management in ServiceNow adds candidate/promotion workflow). A security incident involves a security event (breach, malware, phishing) and lives in Security Incident Response (sn_si_incident) with its own confidentiality and process. Any of these can start life as a normal incident and be promoted/converted.

Logging → categorization → prioritization (impact × urgency) → assignment/routing → investigation and diagnosis → resolution (fix or workaround) → closure (with user confirmation window). Escalation — functional and hierarchical — runs across the middle stages.

The primary cmdb_ci and business_service fields hold one each; use the Affected CIs (task_ci) and Impacted Services (task_cmdb_ci_service) related lists to attach as many as needed.

OOB, the property glide.ui.autoclose.time (with the "Autoclose incidents" scheduled job) closes resolved incidents after N days. Custom variant: your own daily scheduled job querying state=Resolved and resolved_at <= N days ago. Quote the OOB property first — it shows platform knowledge.

Impact = breadth of damage (enterprise / department / individual). Urgency = how fast it must be addressed given business timing. The priority lookup table (dl_matcher / priority data lookup) combines them into Priority — which is why priority is read-only on the form in a well-configured instance.

You change impact and/or urgency, and the data lookup recalculates priority. Directly editing priority is normally locked down (read-only via UI policy/dictionary). If asked "how would you allow it," the answer involves adjusting the data lookup or granting an exception role — while warning it breaks SLA consistency.

Something is broken or degraded → incident. You want something that works as designed (access, hardware, software) → request. Classic trap: "I can't access the shared drive" — broken permission (incident) or never had access (request)? Triage determines which.

Process answer, not heroics: priority order is set by the matrix, not opinion; queue managers work assignment via the priority-sorted queue; SLAs and escalations make aging visible; conflicts over "whose ticket matters more" escalate to the queue/incident manager with data (SLA breach proximity). Mention workload dashboards and round-robin/capacity-based assignment if they push further.

Foundation data (groups, users, roles, schedules), categories/subcategories, the impact-urgency-priority lookup, assignment rules, SLA definitions and schedules, notification set, form layout and views per persona, portal record producer for reporting issues, and knowledge integration. That checklist, delivered in order, is a complete answer.

No. P1 is a priority calculation; major incident is a process declaration. Many P1s resolve quickly without MIM. A major incident is declared (often from P1 candidates) when impact breadth, duration or visibility demands coordinated response and communications. Some organizations also promote lower-priority incidents with executive visibility.

Example: "500 users report email down at 9 AM — walk me through your first 30 minutes." Answer structure: verify and scope (monitoring, CI/service map) → declare major incident if criteria met → assemble resolver group, start comms cadence → parent-child the flood of duplicates against one master incident → workaround/restore → post-restore: link to problem for RCA. The parent-child dedup detail is the part most candidates miss.

A single source of truth for configuration items — the infrastructure, applications and services you manage — and crucially the relationships between them. It powers impact analysis ("what breaks if this server goes down?"), change risk assessment, incident diagnosis and asset/service reporting. Without relationships it's just an inventory.

A Configuration Item: any component that must be managed to deliver an IT service — servers, applications, databases, network gear, and logical items like business services. Each is a record in a class table under the cmdb_ci hierarchy.

cmdb is the root; cmdb_ci is the base CI class everything extends; cmdb_rel_ci stores CI-to-CI relationships. Everything else — cmdb_ci_server, cmdb_ci_appl, etc. — is the class hierarchy extending cmdb_ci.

Directional pairs stored in cmdb_rel_ci with a relationship type: Runs on / Runs, Depends on / Used by, Hosted on / Hosts, Contains / Contained by, Connects to, etc. Each record is parent–type–child; direction matters for impact calculation (upstream/downstream).

The Identification and Reconciliation Engine — the gatekeeper all well-behaved data sources (Discovery, integrations, imports) pass through. Identification rules decide "is this incoming CI the same as an existing one?"; reconciliation rules decide "which source is allowed to update which attributes." IRE is what stands between you and a CMDB full of duplicates.

They define, per CI class, which attribute sets uniquely identify a CI — e.g. serial number, then name+class as fallback. Ordered identifier entries are evaluated until one matches; match → update existing CI, no match → create new. Weak rules create duplicates; overly strict ones create orphans.

They set attribute-level authority between competing data sources: e.g. Discovery owns operating_system, the HR feed owns owned_by. Without them, whichever source ran last wins and sources ping-pong each other's values forever.

The interactive graph (BSM map) launched from a CI showing its upstream and downstream relationships — what it runs on, what depends on it. Used live during incidents and change assessment to see blast radius.

Same laptop, two lenses. The asset (alm_asset) tracks financial/lifecycle facts: cost, ownership, contract, depreciation, stockroom. The CI tracks operational facts: configuration, relationships, impact. They're linked records, kept in sync by the platform for hardware classes; some things are assets but never CIs (a mouse) and vice versa (a business service).

• cmdb_ci_computer / cmdb_ci_server — physical/virtual compute.
• cmdb_ci_appl — running application instances.
• cmdb_ci_db_instance — database instances.
• cmdb_ci_netgear — network devices.
• cmdb_ci_service — business/application services (the layer incidents and changes should point at).

Correctness (data is accurate), Completeness (required attributes and CIs are present), Compliance (data follows governance rules — staleness, orphans, duplicates within thresholds). They're the three axes the CMDB Health Dashboard scores.

The OOB dashboard scoring CMDB health across correctness/completeness/compliance KPIs — duplicate CIs, stale CIs, orphaned records, required-field coverage — with drill-down to the offending records and remediation jobs. It's the governance instrument you cite when asked "how do you keep a CMDB healthy?"

Scheduled attestation campaigns: designated owners receive certification tasks to review and confirm (or correct) their CIs' attributes. It brings human accountability to the data that Discovery can't verify — ownership, cost center, criticality.

Service Mapping builds top-down, service-centric maps: starting from a service entry point (a URL), it traces the actual delivery chain — load balancer → web tier → app → database — and writes those CIs and relationships into the CMDB. Discovery answers "what exists?"; Service Mapping answers "what makes up this service?"

For synchronized classes, creating one auto-creates the other: a new cmdb_ci_computer spawns its alm_hardware record and vice versa, linked via the asset/ci reference pair. The mapping is controlled by the asset class → CI class relationship (Model categories define which classes sync).

Runs on links software to the compute executing it: application runs on server. Hosted on expresses hosting/containment of one infrastructure element by another — e.g. a VM hosted on an ESXi host, a server hosted on a cloud resource. Rule of thumb: process-to-machine = runs on; machine-to-platform = hosted on.

You lose its relationships (cmdb_rel_ci rows cascade), break references from incidents/changes/problems that pointed at it, distort impact maps, and lose history. That's why the lifecycle approach — mark Retired/Absent via status fields and let IRE handle disappearance — is preferred over deletion; deletion is reserved for junk data, ideally after archiving.

Find: CMDB Health duplicate KPIs and de-duplication tasks, or a GlideAggregate on the identifying attributes (serial_number, name+class) with HAVING COUNT > 1. Fix: the Duplicate CI Remediator merges survivors and re-points references. Prevent: fix the identification rules and force all sources through IRE — otherwise the duplicates return next Discovery run.

Discovery automatically finds infrastructure on your networks — servers, VMs, network devices, storage, cloud resources, the software on them — and populates/refreshes the CMDB with CIs and relationships. The problem it solves: manually maintained CMDBs are stale the week after they're built.

1. Scanning — port scan of the IP range to detect what's alive and what protocol it speaks.
2. Classification — log in and determine device type/class (Windows? Linux? Router?).
3. Identification — match against existing CMDB CIs via IRE: update or create.
4. Exploration — gather deep attributes: hardware, software, running processes, connections.

A Java application installed inside your network that executes probes/patterns locally and relays results to the instance over outbound HTTPS. The instance sits in ServiceNow's cloud and cannot reach your private network — the MID Server is its arms and legs behind your firewall. All communication is MID-initiated (outbound), which is the security selling point.

Legacy model: a probe collects data on the MID Server; its paired sensor processes the returned payload on the instance and updates the CMDB. Patterns are the modern replacement — declarative step sequences (used by both Discovery and Service Mapping) that do collection and parsing in one definition, easier to extend without Java/probe internals.

Agentless network discovery (the classic IP-range scan via MID Server), cloud discovery (AWS/Azure/GCP via APIs), serverless/config-file based discovery, and agent-client collector (ACC) based discovery for endpoints where agents fit better. Also "horizontal" (infrastructure-wide) vs "top-down" (Service Mapping) as the conceptual split.

The ecc_queue table is the message bus between instance and MID Servers: output records are work orders for the MID (run this probe/pattern), input records are results coming back. Discovery debugging usually starts here — find the input/output pair and read the payload.

Read-level credentials per technology: SNMP community strings (network gear), Windows (WMI/WinRM domain account), SSH for Linux/Unix, and API keys for cloud/applications. Stored encrypted in the credentials table, resolved by the MID Server at runtime, optionally via an external vault (CyberArk). Classification and exploration phases need to authenticate — scanning alone can't classify.

The record defining a run: IP ranges to scan, which MID Server/cluster executes it, when it runs (cron-style), max run time, and behavior options. Practical guidance: schedule subnets separately, run during quiet windows, and stagger to keep MID load sane.

A behavior assigns different discovery functionality across multiple MID Servers for one schedule — e.g. MID A does SNMP from the DMZ while MID B does WMI inside the domain, against the same ranges. Use them in segmented networks where no single MID Server has all the access.

Discovery's identification phase submits its payload through the Identification and Reconciliation Engine — the same identification rules and datasource precedence that govern any other source. That is why fixing duplicates means fixing identification rules, not patching Discovery.

The staples: SNMP 161, SSH 22, WMI 135 + dynamic RPC range / WinRM 5985-5986, plus protocol-specific ports for storage and applications. Firewall rules must allow the MID Server to reach targets on those ports; blocked ports show up as devices classifying as "unknown" or partial data. MID-to-instance needs only outbound 443.

Discovery is horizontal: sweep the network, find everything, populate infrastructure CIs and basic relationships. Service Mapping is top-down: start from a service entry point and trace only what delivers that service, producing an accurate service map. They share MID Servers, patterns and IRE; mature shops run both.

Identification rules match it (serial number, network identifiers…), so IRE updates the existing CI rather than creating a new one — refreshed attributes, refreshed relationships, updated last-discovered timestamp. Duplicates mean the match failed: weak identifiers or dirty existing data.

One record per Discovery run (discovery_status): counts of devices scanned/classified/identified, errors, timing, and links to the per-device Discovery Log and ECC queue entries. It's the first stop when someone says "Discovery missed my server."

A Service Level Agreement — a time-bound commitment on a task (respond in 30 minutes, resolve in 8 hours). In the platform: an SLA Definition (conditions + duration + schedule) that attaches a Task SLA record to matching tasks, tracked by the SLA engine through pause/resume/breach.

By the Type field on the definition: SLA (commitment to the customer), OLA (internal team-to-team commitment), Underpinning Contract (commitment from an external vendor). Functionally they behave the same; the type documents who owes whom.

An option making the SLA clock start from an earlier field value (usually opened_at) instead of the moment the SLA attached. Example: P2 SLA attaches only when priority becomes P2 an hour after opening — with retroactive start, that first hour counts against the target.

The schedule defines which hours count: an 8-hour SLA on a "Mon–Fri 9–17" schedule ignores nights and weekends; on a 24×7 schedule it's 8 wall-clock hours. Schedule + timezone selection is where most "why did/didn't this breach?" mysteries resolve.

When conditions change (P2 → P1), the P2 SLA's stop/cancel conditions end it (Completed or Cancelled state on the task SLA) and the P1 definition attaches a fresh task SLA. Both records remain visible in the Task SLAs related list — history is preserved, which matters for reporting.

Repair recalculates existing task SLA records after you fix a definition, schedule or data problem — re-running the engine's math over the task's audit history. Run it on a task, a filtered set, or per definition (SLA → Repair). Without repair, fixed definitions only affect future attachments.

Move the configuration (SLA definitions, schedules, properties) via update sets, and the data (task SLAs with their timing fields, plus the task audit trail) with a data migration that preserves sys_ids and timestamps (autoSysFields(false), setWorkflow(false) — documented!). Then run SLA repair on migrated records to let the engine recompute consistently against the migrated audit data. Test breach math on samples before cutover.

The condition that completes the SLA — typically "state is Resolved". When it evaluates true, the clock stops permanently and the task SLA records whether it met or breached the target. Distinct from pause (temporary, e.g. Awaiting Caller) and cancel (SLA no longer applies).

Response measures time to first meaningful action — acknowledged/assigned/first comment; stop condition is that acknowledgment. Resolution measures time to fix — stop condition is Resolved. A P1 might carry "respond in 15 min" and "resolve in 4 h" as two separate definitions running in parallel.

Each priority's SLA definition attaches when its condition becomes true and stops/cancels when it stops matching — so the incident accumulates multiple task SLA records, each measuring its own window. With retroactive start configured, the newest SLA can count from opened_at instead of its attach moment. The answer they're probing for: one incident, many task SLA records, each with its own clock.

The P2 definition's stop/cancel condition (priority no longer P2) ends that task SLA — it shows as Cancelled (or Completed, per definition config) with its elapsed time frozen. The P1 SLA runs independently from its own start (or retroactively). Nothing is merged; both records tell their part of the story.

Retroactive start: triage takes 40 minutes before the incident is prioritized P2 — the business insists resolution time counts from opened, not from prioritization. Retroactive pause complements it: while recalculating that back-window, time the ticket spent in pause states (Awaiting Caller) is excluded, so the agent isn't penalized for customer wait time that happened before attachment.

Yes — the SLA definition's "Timezone source" setting can derive the timezone from a field on the task (e.g. caller's location/timezone) instead of the instance default, so the schedule's business hours are evaluated in the caller's local time.

Actual elapsed is wall-clock time since start, pauses excluded. Business elapsed additionally filters through the schedule — only in-hours time counts. An incident opened Friday 4 PM and resolved Monday 10 AM on a 9–17 schedule: actual ≈ 66 h, business ≈ 2 h.

The companion flag to retroactive start: when the engine back-dates the start, it also reconstructs which portions of that earlier window matched the pause condition and excludes them. Without it, retroactive start unfairly counts time the ticket was legitimately paused before the SLA attached.

The Schedule field picks a fixed schedule for the definition; Schedule source lets it come dynamically from the task or related records (e.g. the assignment group's schedule, or the CI's support schedule) so one definition serves teams with different working hours.