Assess CMDB impact agentic workflow reference
Summarize
Summary of Assess CMDB Impact Agentic Workflow Reference
The Assess CMDB Impact agentic workflow in ServiceNow Zurich release enables automated impact analysis of change requests and incidents by leveraging CMDB topology data and AI-driven reasoning. It evaluates the potential impact of proposed changes or incidents on configuration items (CIs) within your configuration management database (CMDB), helping you understand risk and dependencies before execution.
Show less
Input Modes and Supported Records
This workflow accepts two primary input modes:
- Task record identifier: Change request (e.g., CHG0000015) or incident numbers (e.g., INC0001234) to trigger impact analysis.
- CI sysid plus change context: The sysid of a CI combined with a free-text description of the proposed change (e.g., patching or restarting a server).
Only changerequest and incident record types are supported. Records that are canceled, closed, or new without summaries are either rejected or handled with fallback logic.
Input Resolution and Processing
The workflow extracts descriptive context from the task record using AI to summarize key sections:
- Change requests: Extracts Objective and Risk sections.
- Incidents: Extracts Issue section.
If no suitable summary is available, it falls back to the record’s shortdescription or description field.
Output Schema
The workflow outputs a structured list of impacted CIs, each with:
- sysId: Unique CI identifier from the CMDB topology.
- ciName: Display name of the CI.
- ciClass: Class of the CI (e.g., Linux server, application server).
- impactLevel: Severity categorized as high, medium, low, or none.
- impactType: Category such as availability, performance, security, etc.
- confidence: Confidence level in the assessment (high, medium, low).
- reason: Plain-language explanation including dependency and propagation analysis.
Topology Traversal and Limits
The workflow uses a three-phase breadth-first search through CMDB relationships to build dependency topology. A system property limits traversal to a maximum of 250 CI nodes to control performance and scope.
Limitations and Error Handling
- The analysis only considers CMDB topology semantics and does not factor in past changes, ongoing incidents, scheduled changes, or business context.
- Accuracy depends on the quality and detail of the change description; vague inputs reduce assessment quality.
- Common errors include missing CI association, absent descriptions, or invalid identifiers, with clear error messages guiding resolution.
- An empty impact list is a valid result when no upstream dependencies exist.
Role and Access Requirements
Users must have the itil role to:
- Read CMDB CI records and relationships.
- Read change request and incident records.
- Invoke the Assess CMDB Impact workflow via the ServiceNow Otto panel.
Access to the Otto panel is also required; contact your administrator if it is not visible.
Practical Use for ServiceNow Customers
This workflow helps your teams quickly perform impact analysis on changes or incidents by automatically analyzing CI dependencies and providing detailed impact severity and reasoning. It supports informed decision-making and risk mitigation in change management processes. Ensure descriptive change and incident records for best results, and verify user roles and Otto panel access to utilize this capability effectively.
Reference information for the Assess CMDB impact agentic workflow, including input modes, output schema, supported record types, constraints, and system properties.
Input modes
| Mode | Inputs | Examples |
|---|---|---|
| Task record |
Change request or incident number. For example, |
“Help with the impact analysis for CHG000015”, "What is the impact of CHG0001234?", "Help me do the impact analysis for INC0001234" or "Analyze the impact of CHG0001235". |
| CI_SYSID plus Change context |
|
"what would be the impact if I patched this server?" or "Analyze the impact of restarting server abc12345. We need to apply a kernel patch and restart". |
Supported record types
For invocation by change record, the workflow processes these record types:
change_request(Change)incident(Incident)
Any other record class is rejected. Additionally, cancelled or closed records aren't processed:
- Change requests in state 4 (Canceled) are rejected
- Change requests in state 5 (New) skip LLM-based summarization; the agentic workflow uses record fields as fallback
- Incidents in state 8 (Closed) are rejected
Input resolution
For invocation by change record, the workflow extracts the change description by using an AI summary of the task. The summary includes:
- For change_request: Objective and Risk sections from the change summary
- For incident: Issue section from the incident summary
If the task summary is unavailable or does not match the expected schema (for example, a New-state change request with no summary content available), the workflow falls back to the record's short_description or
description field.
Output schema
The workflow returns a structured list of impacted items. Each item has the following schema:
| Field | Values | Description |
|---|---|---|
sysId |
String | CI sys_id from CMDB topology (unique identifier; for example, a1b2c3d4e5f6g7h8) |
ciName |
String | CI display name (for example, "web-node-01" or "payment-gateway-prod") |
ciClass |
String | CI class name (for example, "cmdb_ci_linux_server", "cmdb_ci_app_server", "cmdb_ci_db_instance") |
impactLevel |
high | medium | low | none | Severity of impact on this CI |
impactType |
availability | performance | data-integrity | functional | security | operational | none | Category of impact (for example, availability loss, performance degradation) |
confidence |
high | medium | low | Confidence in the assessment |
reason |
String | Plain-language explanation including redundancy assessment and propagation reasoning |
Topology traversal
cmdb_rel_ci):- Resolve inputs.
- Fetch topology.
- Invoke LLM.
System properties
| Property | Default | Description |
|---|---|---|
sn_cmdb_gen_ai.impact_analysis.max_topology_nodes |
250 | Maximum number of CI nodes to include in the CMDB topology traversal. When the limit is reached, traversal terminates and only the accumulated nodes are sent to the LLM for impact assessment. |
Limitations
The Assess CMDB impact agentic workflow considers only the semantics of CMDB topology. It does not include data on similar past changes, ongoing incidents, upcoming scheduled changes, or business context.
LLM reasoning accuracy depends on the richness and clarity of the change description provided. Short or vague descriptions produce lower-quality impact assessments.
Error handling
| Situation | Response |
|---|---|
| Change record exists but has no associated CI | Error: cannot determine topology — change record has no CI |
| Change record has no description (and fallback fails) | Error: change record has no description. Populate the change record's description or risk fields and try again. |
| Provided change_id does not exist | Error: change record not found |
| Provided CI sys_id does not exist in CMDB | Error: CI not found |
| CI exists but has no upstream dependencies | Empty impact list (valid result, not an error) |
Role requirements
Access to the Assess CMDB impact agentic workflow requires the itil role to perform the following actions:
- Read CMDB CI records and CI relationship data
- Read change request and incident records
- Invoke the Impact Analysis agentic workflow from the ServiceNow Otto panel
Additionally, users must have access to open the ServiceNow Otto panel from their workspace or application. Contact your administrator if you can't see the ServiceNow Otto icon.