ServiceNow CIS-ITSM cheat sheet

ITIL 4's four dimensions: organizations and people, information and technology, partners and suppliers, and value streams and processes.

Service value chain activities: Plan, Improve, Engage, Design and Transition, Obtain/Build, and Deliver and Support.

Service value system components: guiding principles, governance, the service value chain, practices, and continual improvement.

ServiceNow ITSM core applications: Incident, Problem, Change, Knowledge, Service Catalog/Request, CMDB, and Service Level Management.

Priority is derived from impact and urgency: impact describes the breadth of the effect, urgency describes how quickly resolution is required.

The itil role bundles sn_incident_write, sn_problem_write, and sn_change_write; read-only access is granted by sn_incident_read, sn_problem_read, and sn_change_read.

Process handoffs: incident to problem ('Create Problem'), incident to change ('Create Change'), problem to change (for the permanent fix), problem to known error (documented workaround).

ITIL 4 practices tested by this exam include incident management, problem management, change enablement, service desk, service request management, service level management, knowledge management, and service configuration management.

Default incident states: New, In Progress, On Hold, Resolved, Closed, and Canceled.

On Hold reasons: Awaiting Caller, Awaiting Change, Awaiting Problem, and Awaiting Vendor.

Priority comes from the impact and urgency matrix; P1 is the highest priority and P5 the lowest.

An incident cannot move to Resolved until a resolution code and resolution notes are entered.

Reopen rule: when a caller adds a comment to a resolved or closed incident, the record can return to In Progress if reopen behavior is enabled.

Child incidents are linked to a parent incident when many users are affected by one underlying issue.

Assignment uses assignment rules, assignment groups with round-robin or least-loaded balancing, or Advanced Work Assignment.

Task SLA records attached to an incident pause when the SLA definition's pause condition is met, typically state = On Hold.

Major incidents are driven from the Major Incident Workbench, which handles stakeholder communication, related incidents, and post-incident review.

Problem states: New, Assess, Root Cause Analysis, Fix in Progress, Resolved, and Closed.

The 'Create Problem' related link on an incident creates a problem record and links the incident on the problem's related incidents list.

A known error is a problem with a documented root cause and workaround; set the Known error flag and populate the workaround field.

Problem tasks are child records that split root cause analysis and fix work into assignable units.

Moving a problem to Fix in Progress typically results in a change request that delivers the permanent fix.

Reactive problem management starts from incidents; proactive problem management starts from trend analysis and monitoring data.

Problem closure requires cause notes, fix notes, and close notes.

Workarounds can be published as knowledge articles so the service desk can apply them to matching incidents.

Change types: standard (pre-approved), normal (requires change manager or CAB approval), and emergency (expedited approval).

Normal change state flow: New, Assess, Authorize, Scheduled, Implement, Review, Closed; Canceled is reachable from the active states.

Standard changes are created from standard change templates and require no CAB approval.

Change models define which states, approvals, tasks, and conditions apply to a given change type.

Risk is derived from impact and likelihood, often through a risk assessment questionnaire, and drives the approval requirements.

The change schedule and CAB workbench surface planned changes and detect planning conflicts and blackout windows.

An unauthorized change is a change made to a CI without an approved change request, detected when actual state differs from authorized state.

Affected CIs are the configuration items the change will modify; impacted CIs are those affected indirectly.

Emergency changes use an expedited approval path, typically from the emergency CAB (ECAB).

Article states: Draft, In Review, Published, and Retired.

Knowledge bases (kb_knowledge_base) contain articles (kb_knowledge); each has an owner and an ownership group.

User criteria control which users can read or cannot read a knowledge base or an individual article.

Lifecycle: Draft, then In Review, then Published, then Retired; a retired article stays on record but drops out of search results.

Knowledge blocks hold reusable content that can be embedded in multiple articles and updated in one place.

Article templates predefine fields and structure for a category of article.

Feedback features include ratings, comments, and the 'flag article' action to request review.

Only members of the ownership group holding knowledge roles can create, edit, and publish the group's articles.

Core tables: sc_catalog, sc_category, sc_cat_item (catalog item), sc_request (request), sc_req_item (requested item), and sc_task (catalog task).

One request can contain multiple requested items; each requested item is fulfilled independently with its own tasks and approvals.

Record producers create a record on another table, such as an incident, instead of generating a requested item.

Order guides bundle multiple catalog items into a single ordering experience.

Variables capture user input; variable sets let the same group of variables be reused across many catalog items.

Two-step checkout: the first step submits the order, the second displays the created request and requested items.

Fulfillment runs through Flow Designer flows or workflows, which generate catalog tasks for the fulfilling groups.

Approvals can be defined at the request level, the requested item level, or both.

All CI classes extend cmdb_ci, including cmdb_ci_server, cmdb_ci_appl, and cmdb_ci_service.

CI-to-CI relationships are stored in cmdb_rel_ci with types such as Depends on, Used by, Contains, and Runs on.

The Identification and Reconciliation Engine (IRE) uses data source precedence, identification rules, and reconciliation rules to create or update CIs.

CMDB health is measured with completeness, correctness, and compliance KPIs that flag orphan, duplicate, and stale CIs.

CSDM provides a prescriptive set of CI classes and relationships layered from Foundation (shared data) through Design, Build, and Manage.

Discovery and Service Mapping populate and maintain the CMDB automatically.

CI lifecycle values include Planned, Install, Operational, and Retired.

Reconciliation rules decide which data source wins for an attribute when multiple sources supply conflicting values.

An SLA definition specifies the task table (incident, problem, change, or sc_req_item), start, pause, and stop conditions, duration, and schedule.

Task SLA records (task_sla) are created when a task meets the start condition and track stage, elapsed percentage, and breach.

Task SLA stages are In Progress, Paused, and Completed; the breach flag is set once the target time passes.

The attached schedule (for example 8x5 weekdays) determines which hours count toward the SLA.

OLA and underpinning contract are SLA definition types used for internal team commitments and vendor commitments respectively.

Service level commitments defined on service offerings present response and resolution targets to requesters in the catalog.

Retroactive start lets an SLA begin from the task's creation time rather than the moment the start condition was met.

Breach handling uses notifications, escalations, and workflow; the SLA timeline shows elapsed and remaining time.

The repair/reset SLA UI action restarts the SLA clock when the target must be recalculated.