Change impact analysis in ServiceNow is only as good as the relationships in your configuration management database (CMDB). When a change names an affected configuration item (CI), the impacted services are worked out by following that CI's relationships upwards to the applications and services it supports. If a relationship is missing, the calculation doesn't come back as "unknown". It comes back as "no impact", and the change advisory board approves a change that takes down a service nobody listed.
This article explains how that calculation works, why a missing relationship is more dangerous than a missing CI, and the checks we put in place so impact analysis can be trusted on the changes that matter. For the underlying model, our overview of what a CMDB is and how it works sets out how CIs and relationships fit together.
A change record carries a list of affected CIs. That's the part a person fills in, or that's populated from the CI the change was raised against.
Impacted services are derived. The platform follows the relationships and service maps from each affected CI up to the application services and business services above it. The result is what the change advisory board reads when it judges risk, and what the service owners are asked to approve.
So the quality of the answer depends on two things the requester never sees. The first is whether the right CI was named. The second, and the one that usually fails, is whether every service that depends on that CI is actually connected to it in the CMDB.
A missing CI is at least visible. Someone tries to raise the change, can't find the device, and asks why.
A missing relationship is silent. The CI exists and looks complete. It has an owner, a class and a support group. It simply isn't linked to three of the four services that run on it, so impact analysis lists one service and stops.
Nobody at the change advisory board has a reason to question that. The output looks precise. It's a named service, pulled from the system of record, and it matches what the requester expected. The only people who know it's wrong are the ones whose applications aren't on the list.
We saw exactly this at a broadcaster with an estate of around 15,000 CIs.
Services had been mapped by tagging. Application managers were asked to tag the infrastructure their applications used, and the service maps were built from those tags. Everyone believed the maps captured the components underneath each business application.
They didn't, because much of the infrastructure served more than one application. Each application manager had tagged a shared component with the application they considered most important, and left it there. One tag per component. One service per map.
A change was then raised against a critical piece of that shared infrastructure. Impact analysis showed its primary application only. When the device was taken offline, several business applications and services failed with it, including the application that runs the advertising schedule.
Advertising is the company's main source of income. For the duration of the outage, commercial breaks went out with no commercials in them. The lost advertising revenue came to $600,000, and the share price fell by 4%.
A later application audit found that the applications that failed had no service maps at all. Problem management linked the incidents back to the change only after the fact. We replaced the tag-based approach with top-down, pattern-based service mapping, so relationships are built from how the application actually runs rather than from someone's memory of it.
Tagging isn't wrong in itself. It fails in predictable places, and they're worth knowing before you rely on it for change.
Top-down, pattern-based mapping starts from the service's entry point and follows what it actually connects to. That's why it finds the second, third and fourth application on a shared component. For more on how this works, see our page on ServiceNow Service Mapping.
You don't need to remap the whole estate to reduce the risk. These steps target the changes most likely to cause the next outage.
Track the results as key performance indicators (KPIs): critical applications with a current service map, shared-component CIs verified in the last quarter, and changes whose incidents revealed a missing relationship. The last one should fall over time. If it doesn't, the relationships aren't being fixed after each lesson. Our article on what slows down incident resolution shows the same gaps from the incident side.
Our two-week CMDB health baseline scores which of your CIs are trustworthy and which are guesses, including the relationships that impact analysis depends on. The output is a report built for your change advisory board, so you can see which changes are being approved against incomplete maps.
Where the gaps come from missing data sources, our discovery and integration coverage review establishes what's missing from your estate view, where it's missing, and what it costs you during an incident. It's scoped at an initial consultation against your estate.
Book a CMDB diagnostic call or arrange a meeting with one of our consultants.
It starts from the affected CIs on the change record and follows their relationships and service maps upwards to the application and business services they support. The accuracy of the result depends entirely on those relationships being complete.
Usually because a relationship was missing. A CI with no link to a service produces no impacted services, which reads as no impact rather than unknown impact.
It works for components that serve one application. It tends to fail on shared infrastructure, because people tag a component with one application and move on. Top-down, pattern-based mapping finds the others.
Start with shared components and critical business applications. Verify their relationships first, because that's where a missing link causes the widest outage.