Assess CMDB impact agentic workflow reference

  • Release version: Australia
  • Updated July 7, 2026
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Assess CMDB impact agentic workflow reference

    The Assess CMDB impact agentic workflow in ServiceNow Australia release enables automated analysis of the impact of change requests or incidents on your Configuration Management Database (CMDB) topology. It accepts specific inputs, processes supported record types, and returns a structured impact assessment. This workflow helps customers understand potential risks and operational impacts of proposed changes or incidents by leveraging CMDB relationships and AI-driven summarization.

    Show full answer Show less

    Input Modes and Supported Records

    • Input types: The workflow accepts either a task record number (change request or incident) or a combination of CI sysid and a free-text change context description.
    • Supported record types: Only changerequest and incident records are processed. Records that are canceled, newly created without summaries, or closed are either rejected or handled with fallback logic.
    • Input resolution: AI-generated summaries extract relevant objective, risk, or issue sections from change or incident records to inform the analysis. If unavailable, short descriptions or descriptions are used.

    Output Schema

    The workflow returns a detailed list of impacted Configuration Items (CIs) with the following attributes:

    • sysId: Unique CMDB identifier of the CI.
    • ciName: Display name of the CI.
    • ciClass: Class/category of the CI (e.g., server, database instance).
    • impactLevel: Severity of impact categorized as high, medium, low, or none.
    • impactType: Nature of impact such as availability, performance, security, etc.
    • confidence: Confidence level of the assessment (high, medium, low).
    • reason: Plain-language explanation including dependency and propagation details.

    How It Works

    • Builds the dependency topology by performing a breadth-first search through the CMDB relationship table, limited to a configurable maximum number of nodes (default 250).
    • Utilizes AI (LLM) to analyze the impact based on topology and change context.

    Constraints and Limitations

    • Only semantic CMDB topology data is considered; it does not factor in historical changes, ongoing incidents, scheduled changes, or business context.
    • Quality of AI reasoning depends on the clarity and detail of change descriptions; vague inputs reduce accuracy.
    • Topology traversal stops when the node limit is reached, potentially limiting the scope of analysis.

    Error Handling

    • Errors reported when change records lack associated CI, descriptions, or if provided identifiers do not exist in the CMDB.
    • Empty impact lists indicate no upstream dependencies and are valid outcomes.

    Role and Access Requirements

    • Users must have the itil role to read CMDB data, change and incident records, and invoke this workflow.
    • Access to the ServiceNow Otto panel is required to run the workflow; contact administrators if access is unavailable.

    Reference information for the Assess CMDB impact agentic workflow, including input modes, output schema, supported record types, constraints, and system properties.

    Input modes

    Table 1. Input types
    Mode Inputs Examples
    Task record

    Change request or incident number. For example, CHG0000015 or INC0001234.

    “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

    ciid (sys_id of the cmdb_ci) + changeContext (free-text description of the proposed change)

    "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:

    Table 2. Output 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

    The workflow builds the dependency topology using a three-phase breadth-first search (BFS) through the CMDB relationship table (cmdb_rel_ci):
    1. Resolve inputs.
    2. Fetch topology.
    3. Invoke LLM.

    System properties

    Table 3. 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

    Table 4. Error scenarios and responses
    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.