Change Management with Blast Radius

Last Updated: September 28, 2026
Estimated Reading Time: 7 minutes

Overview

This guide shows how to use cmdbx impact analysis in your change management process. cmdbx gives change reviewers evidence: the CIs and services that a change can affect, the paths that connect them, and how much the evidence can be trusted.

cmdbx has two tools for change review:

ToolUse it when
Blast Radius SimulatorYou want to examine one CI in the Dependency Map.
Change Impact AnalysisA ServiceNow change request has more than one affected CI. ServiceNow sends all of them to cmdbx for one merged analysis.

Both tools use the same deterministic, versioned relationship rules. They follow impact from the changed CI to the CIs and services that depend on it.

When to Use Impact Analysis

  • Server maintenance: assess the impact before you patch or restart a server.
  • Infrastructure upgrades: understand the dependencies before a hardware change.
  • Application deployments: identify the affected services.
  • Decommissioning: confirm that no critical service depends on the CI.
  • Changes with more than one CI: find the services that more than one changed CI reaches.

Step 1: Make Sure That the Evidence Is Fresh

  1. Examine the sync status in the top bar.
  2. If the last sync is old, run a sync before an important review.
  3. Confirm that the active environment is correct.

Impact analysis can only be as good as the CMDB relationships. Every result reports its evidence confidence. Stale or incomplete topology lowers confidence.

Step 2: Run the Analysis

For One CI

  1. Go to Dependency Map.
  2. Find the CI.
  3. Right-click the CI and select Simulate Outage.
  4. Set the depth. Start with depth 3 to 5.

For a Change Request With More Than One CI

Your ServiceNow administrator configures a Flow or UI action that sends the change request and its affected CIs to cmdbx. cmdbx returns a summary and a ready-to-post work note. See Change Impact Analysis.

Step 3: Interpret the Results

Review these parts of the result:

  • Direct and indirect impact: how many CIs and services the change can affect, and how far away they are.
  • Important services: the business services in the result.
  • Paths: how each impacted CI connects to the changed CI.
  • Shared impact: for a merged analysis, the CIs that more than one changed CI reaches.
  • Alternate routes and redundancy: whether independent modeled routes exist.
  • Modeled bottlenecks: single points of failure that every path passes through.
  • Evidence confidence and limitations: whether stale data or an analysis limit reduces trust in the result.

Risk is a model-based priority, not a probability of an outage. A modeled alternate route does not prove that failover works. Confirm redundancy with the service owner.

Step 4: Decide the Review Path

cmdbx does not set your change policy. Use the result as evidence in your existing process. For example:

  • A change that reaches important services, or that passes through a modeled bottleneck, usually needs CAB review.
  • A result with Low evidence confidence needs a manual check with the service owners before approval.
  • A change with no path to any service can often follow a standard change process.

Step 5: Document the Evidence

Include in the change request:

  1. The PDF export of the blast radius, or the cmdbx work note from a merged analysis.
  2. The important services and the modeled bottlenecks.
  3. The evidence confidence and any limitations.
  4. Your mitigation plan and your rollback plan.

The PDF and CSV exports come from the saved result. They do not change after you export them.

Integrate With Your Change Process

Before the Change

  • Run the analysis when you create the change request.
  • Route the change based on the result and your policy.
  • Notify the owners of the affected services.

Before Implementation

  • Run the analysis again if the CMDB synced since the first run.
  • Confirm that your mitigation and rollback plans are ready.

After the Change

  • Go to CMDB > Activity and review the changes from the next sync.
  • If the change affected a CI that the analysis did not show, a relationship is probably missing. Add it in ServiceNow.
  • Update the business criticality of a CI if the impact was larger than expected.

Improve Impact Accuracy Over Time

  • Fix missing relationships that you find during changes.
  • Work on the relationship and freshness issues in Remediation.
  • Review drift that no change request covered in CMDB Activity.
  • Resolve modeled bottlenecks, or model real redundancy, in ServiceNow.

Best Practices

  1. Run impact analysis before every non-standard change.
  2. Sync before important reviews. Fresh evidence gives higher confidence.
  3. Check confidence before risk. A high score on weak evidence is not a reliable answer.
  4. Analyze all affected CIs together when a change touches more than one CI.
  5. Compare the prediction with the result after the change, and fix the CMDB where they differ.

Related Articles