Analyzing the impact of a change or incident
Summarize
Summary of Analyzing the impact of a change or incident
The Assess CMDB impact agentic workflow in ServiceNow helps change managers and incident responders understand the potential impact of changes or incidents on upstream services and configuration items (CIs). Unlike traditional methods that rely on simple lists of related services, this workflow uses the CMDB dependency graph combined with large language model (LLM) reasoning to assess the likelihood and severity of impact based on the nature of the change and the topology of relationships.
Show less
This approach enables more accurate, semantic impact analysis that goes beyond topology to include redundancy and propagation logic, helping organizations make better-informed decisions prior to change approval or incident resolution.
Key Features
- Automated Impact Assessment: Automatically traces upstream CMDB dependencies from a change or incident record or directly from a CI and description.
- Semantic Reasoning: Uses an LLM to evaluate impact severity (High, Medium, Low, None) and provides clear, plain-language explanations including redundancy considerations.
- Structured Output: Returns a detailed list of impacted CIs with impact level, type (availability, performance, security, etc.), confidence, and reasoning.
- Flexible Invocation: Can be triggered from change or incident records, or directly with CI and description inputs, supporting various operational scenarios and automation workflows.
- Integration with ServiceNow: Accessible via the Otto panel and agentic workflows, fitting seamlessly into existing change and incident management processes.
How It Works
- Step 1 - Resolve Input: Extracts the affected CI and description from a change or incident record, or accepts direct input.
- Step 2 - Fetch Topology: Performs a breadth-first search of the CMDB to build a subgraph of upstream dependencies (up to 250 CIs by default).
- Step 3 - LLM Assessment: Sends the topology and context to an LLM which analyzes impact likelihood and severity, returning a structured impact report.
Important Considerations
- The quality and clarity of the change description directly affect the accuracy of the LLM’s impact assessment.
- Impact analysis depends heavily on the completeness and correctness of the CMDB relationship data.
- Service Mapping relationships are not currently included in the topology traversal.
- The workflow can process a maximum of 250 topology nodes and up to 15,000 LLM input tokens; large or complex topologies may require truncation.
- Access requires the itil role to read CMDB data and view change or incident records.
- Always validate AI-generated impact assessments against your organization’s change governance policies before approving changes.
Practical Application for ServiceNow Customers
By using this workflow, ServiceNow customers can streamline and enhance their impact analysis process, reducing manual effort and guesswork. Change managers and CAB members receive prioritized impact information with clear reasoning, enabling better risk assessment and scheduling decisions. The workflow supports both standard change and incident management practices and can be integrated into automated agentic workflows for faster and more consistent impact evaluations.
The Assess CMDB impact agentic workflow identifies the upstream services and CIs that are likely to be affected by an incident or by a proposed change. The workflow reasons about propagation likelihood based on CMDB dependency topology and the nature of the change. The workflow returns a structured list with impact levels and the reasoning.
Generative AI might produce inaccurate or incomplete information. Impact analysis output depends on the quality of the change description and CMDB relationship data. Always validate AI-generated impact assessments against your organization's change governance policies before approving a change.
What is it
The Assess CMDB impact agentic workflow solves a key gap in change management. Today's impact assessment process relies on flat lists of topologically related services with no semantic reasoning about which services will actually be disrupted, or how severely. Change managers must trace CMDB relationships manually and apply institutional knowledge to assess blast radius.
The workflow reads the affected CI from a change record (or accepts a CI plus description directly), traverses the upstream CMDB dependency graph, and uses an LLM to reason about propagation likelihood given the nature of the change and each CI's role in the topology. The result is a structured list: each upstream service or CI with an impact level (High, Medium, Low, or None) and a plain-language reason explaining the assessment.
Key benefits
The workflow provides the following benefits:
- Reduces manual CMDB relationship tracing and guesswork for change approval decisions.
- Provides semantic reasoning about impact severity and likelihood, not just topological relationships.
- Surfaces redundancy awareness. For example, recognizing that a 3-node web tier can absorb the loss of one node.
- Helps Change managers and CAB members make informed approval and scheduling decisions before meetings.
- Is invoked directly from the ServiceNow Otto panel or as part of agentic workflows.
How it works
The workflow executes three sequential steps:
- Step 1: Resolve input
-
Resolves the CI and a context description from a change record (change request or incident) or from direct CI and description input. For change records, the description is extracted from the NowAssist task summary (Objective and Risk sections for change requests; Issue section for incidents). If the summary is unavailable, the workflow uses the record's
short_descriptionordescriptionfield. - Step 2: Fetch topology
-
The workflow performs a three-phase breadth-first search (BFS) traversal of the CMDB relationship graph to build a topology subgraph:
- Step 3: LLM assessment
-
The workflow sends the topology graph and change context to an LLM for impact analysis. The LLM returns a structured assessment with impact level, impact type, confidence, and reasoning for each affected CI.
Invocation modes
- By change or incident task
-
Invoke with a change or incident record. The workflow reads the change's associated CI and extracts the change description from the record. Supported types: change_request and incident. Other record types or cancelled changes (change_request state 4, incident state 8) are rejected.
- By CI directly
-
Invoke with a CI sys_id and a caller-supplied change description. The description is used as-is without change record lookup. Useful for agentic workflows, CI record workspace actions, or scenarios where no change record is available.
See Assess CMDB impact agentic workflow reference for detailed API specifications and error handling for each mode.
Output format
The workflow returns a structured list of impacted items. Each item includes:
- CI name and class: Display name and CMDB class (for example, cmdb_ci_linux_server)
- Impact level: High, Medium, Low, or None
- Impact type: Availability, Performance, Data Integrity, Functional, Security, Operational, or None
- Confidence: Confidence in the assessment: High, Medium, or Low
- Reason: Plain-language explanation including redundancy assessment and propagation reasoning
Constraints and limitations
- Maximum topology nodes: 250 CIs maximum per traversal. Configurable by the
sn_cmdb_gen_ai.impact_analysis.max_topology_nodessystem property. - Maximum LLM input tokens: 15,000 tokens. Large topologies may require truncation or summarization
- Service Mapping not integrated: Service association relationships (svc_ci_assoc) aren't included.
- No relationship type exclusion: All relationship types are traversed. Relationship filtering is not supported.
This workflow considers only the semantics of the Assess CMDB impact agentic workflow topology (actual and probabilistic relationships).
Required role
Access to invoke the workflow requires the itil role to read CMDB CI and relationship data, and to view change records.