OBLYTECH / ServiceNow
The ServiceNow CMDB stores configuration items and their relationships. It is crucial to many IT tasks, including change and incident management procedures, because it offers insights into the IT environment and how its parts depend on each other.
For readers evaluating this topic and deciding what to review next.
Guide map
Start by listing the questions the CMDB must answer, then let those questions decide which records and relationships are kept.
Start by listing which configuration records the team actually uses to make decisions, since those are the ones that need the most care.
Start by deciding which configuration records the team truly needs to trust, because a smaller accurate database beats a large one nobody maintains.
The practical framework
The ServiceNow CMDB stores configuration items and their relationships. It is crucial to many IT tasks, including change and incident management procedures, because it offers insights into the IT environment and how its parts depend on each other.
Common questions
Start with the question, scope, decision boundary, ownership, and evidence that the reader needs to carry into the next action.
Use the article framework to identify the unresolved decision, the responsible group, and the record that will show what happened.
This article is presented as a practical reference. Apply its recommendations against the specific systems, responsibilities, and evidence available in the organization being reviewed.
A CMDB rarely fails because it holds too few records. It fails because two or three sources write the same attribute and nobody decided which one should win. Discovery may report a server’s operating system from the live scan, an import from the procurement file may carry the purchase date, and a manual edit from a support engineer may change the support group. Each of those is correct for its own attribute and wrong for the others. Until the team writes a precedence rule per attribute, every reconciliation run becomes a negotiation between sources.
Ownership of the records themselves is covered in the CMDB ownership model, and the duplicate rules are set out in reconciliation rules and duplicate control. Start with a short list of the configuration item classes that the first services depend on. For each class, name the attributes that matter for the first use case, such as the owning group, the environment, the support status and the relationships to business services. Then assign one authoritative source to each attribute. A source that is authoritative for an attribute is allowed to overwrite it; a source that is not should only fill gaps. That single distinction can remove much of the churn that teams later mistake for data quality problems.
Teams often start with duplicate cleanup because duplicates are the most visible symptom. Cleaning before the rules exist means the same duplicates return within weeks. The sequence below puts the decisions first, so cleanup is a one-time event rather than a permanent job.
When the CMDB looks wrong, the instinct is to fix the record. A faster route is to work out which rule produced the record, because the same cause will produce the same symptom again. The table below gives the pattern most teams see first.
| What the reader sees | Usual cause | First check |
|---|---|---|
| Two records for one physical server with different names | Identifiers use hostname only, and one source stores a fully qualified name | Compare the identifier entries used by each source for that class |
| A manually corrected owner reverts after the next scan | The scan source is authoritative for the owner attribute | Open the source precedence rule and confirm which attribute the scan writes |
| Retired equipment still appears in impact analysis | The record may have been deleted while its relationships or a related service mapping still point to it | Check open relationships before any retirement, and retire rather than delete where history matters |
| Coverage looks high but change reviews still lack information | Records exist but the relationships that connect them to services are missing | Sample a few services and trace from the business service down to the infrastructure |
The CMDB remediation workflow page covers the path from a data-quality finding to a verified correction or an explained exception. The last row matters more than it looks. A CMDB can report many records and still fail the question that matters most, which is what a planned change touches. Relationship coverage for the services in scope is a better measure of readiness than the raw record count. Once those relationships are dependable, service impact analysis is where they earn their keep.
Trust in the CMDB comes from a few repeatable checks, not from a single health score. Track the duplicate count for each in-scope class, the share of in-scope records that have an owner and a support group, and the number of relationships that are present for the services people actually change. Run a small manual sample each cycle, comparing a handful of records with the source system they describe. If the sample disagrees with the CMDB, the score is measuring the wrong thing.
When a measure moves the wrong way, the response depends on the cause. A rise in duplicates after an import usually means the identifiers changed or a new source was added without a precedence rule. A fall in relationship coverage after a migration usually means the relationship builder was not part of the migration scope. Each cause has a different owner, so the review should name one.
A complete CMDB for every class in the estate is rarely the right first project. Connecting operational signals to configuration and service context is the subject of ITOM and CMDB alignment, and that work can wait until the first services are stable. If a class does not feed a decision the business is making now, including it adds reconciliation work and maintenance without a return. Stopping early is a valid choice when the first services are well understood and the remaining classes have no owner yet. It is also worth delaying when the team has not agreed who approves changes to identification rules. Without that owner, every new source creates a new fight.
Usually no. Set the operational status to retired, keep the record for the period the organization needs for audit and history, and close its relationships deliberately. Deleting a record that other records still reference breaks the links that change and incident analysis depend on.
The service owner should own the business services and their dependencies, while the CMDB owner owns the rules that create and maintain the relationships. When both roles sit with one person, check that the person has the time to review them, because relationships go stale faster than attributes.
It is a useful indicator, but it should sit next to two or three plain facts: which services have complete relationships, how many duplicates remain in scope, and how often the sample check disagreed with the source. Leaders can act on those facts, and the score alone rarely tells them what to fund.
Give each source a defined role for each attribute, as described above. An imported record that a discovery scan later confirms should move toward the discovered values for the attributes that discovery owns, and keep the imported values where only the import is authoritative. Without that rule, the two sources keep overwriting each other.
If your CMDB has duplicates that return after every cleanup, the cause is often in the precedence and identification rules rather than in the records. Reviewing those rules, the in-scope classes and the services that depend on them is a practical place to start. Start a CMDB design conversation, or read about CMDB data quality and governance before you decide on the next step.
CMDB accuracy improves when each attribute has one authoritative source, records are matched by clear identification rules, and someone owns the gaps that remain. Fixing data by hand without those three things only produces a cleaner CMDB for a few weeks.
The sequence that usually holds:
Drift is the gap between what the CMDB says and what is running. It shows up as servers that were decommissioned but still appear, relationships that no longer reflect how an application is deployed, and changes made outside the process. It is usually caught by comparing discovery results with the records, reviewing the health dashboard for completeness and correctness, and asking record owners to confirm what they own on a regular cycle.
For the ownership and source decisions, see CMDB data quality and governance. For duplicate handling in detail, read CMDB reconciliation and duplicate control. To track progress over time, the CMDB KPIs and metrics guide lists what to measure, and CMDB classes explained covers how records are structured.
To measure CMDB accuracy, pick a sample of configuration items from each class, compare every attribute you care about with what the live estate shows, and score each record as correct, stale, wrong, missing or duplicated. A total record count says little about accuracy, because a large CMDB can be mostly wrong and still look busy.
Keep the sample small enough for one person to check in a day, spread across the classes that feed incidents and changes, not the whole table. Choose records at random within each class, and include both recently discovered items and ones discovery has not touched for a long time, since those usually fail differently. Pair the sample with the CMDB KPIs and metrics guide.
Use five labels so each result points to a fix:
Stale and duplicate results usually point to discovery and reconciliation rules, so start with how matching is configured. Wrong results point to source authority, meaning which feed is allowed to set a value. Missing results point to a mandatory-field decision that nobody made. Fix the largest category first, then rerun the same sample so the gain is measured, not assumed.
Normalization makes values follow one standard so they can be compared, for example one pattern for operating system names or site locations. Enrichment adds data the record never held, such as an owner or a support group, taken from the system that is the source for that field. Deduplication merges records that describe one item. In most implementations, normalize before you deduplicate, because two records with different spellings of one name will not match until the spelling agrees.
Repeat the sample on a fixed cycle, recording each result beside the change that caused it. Then a series shows which rule moved which category. If the sample turns up more problems than the team can fix in a quarter, a structured review beats another round of manual cleanup; the health check and audit route is built for that.
Many CMDB challenges trace back to four causes: records that cannot be matched reliably, two sources writing the same attribute, attributes with no named owner, and relationships that were never built or have gone stale. Fix them in that order. Each one makes the next cleanup harder to trust, so working on relationships while identification is still weak wastes effort.
Resistance to change and weak stakeholder involvement matter too, but they rarely appear as wrong data. They appear as slow adoption and records that nobody updates. Give them their own owner and a separate plan so they do not hold up the rule work.
| Challenge | What it looks like | First step |
|---|---|---|
| Weak identification | The same server appears twice under two names | Agree match keys per class, with fallbacks for blank serial numbers |
| Competing sources | A corrected value reverts after the next import | Name one authoritative source per attribute |
| No named owner | Records drift and nobody notices until an incident | Assign an owner and a support group to each in-scope class |
| Missing relationships | A change review cannot see which services it touches | Trace a sample of services down to their infrastructure |
Identification comes first. If the match keys are weak, reconciliation runs tend to create new duplicates, and manual cleanup only holds until the next import. Once matching works, the source authority rules for each attribute decide which value survives. Ownership comes third, since an owner cannot keep a record correct while the rules keep overwriting it. Relationships come last because they depend on the other three being stable.
A common surprise in a first review is that relationship gaps can outnumber attribute errors. A server can have a clean name, a correct owner and a current operating system and still sit outside every business service it supports. Confirm the links with discovery and service mapping before you celebrate a low duplicate count. In most implementations the relationship work takes longer than the attribute work, so schedule it up front.
If the relationship gaps are wide, a focused CMDB consulting review can set the identification and ownership rules before bulk reconciliation starts. Doing that first avoids paying twice for the same cleanup.
Fix the routing by fixing the ownership value it reads, not the tickets already sitting in the wrong queue. Where routing reads the group from the configuration item, a stale owner or support group sends every ticket on that item to the wrong team. Reassigning tickets by hand clears one month’s backlog and leaves the cause in place.
Start by tracing one misrouted ticket. Note the group it landed in, open the configuration item it references, and compare the group stored there with the team that runs the service today. If they differ, the routing is doing its job and the data is wrong. If they match, the rule that picks the group needs reading on your own instance, because field names and assignment logic vary by configuration and release.
Stale ownership usually has three sources: a team reorganisation nobody mirrored in the CMDB, an import or discovery feed that writes a group the owner never confirmed, and a manual edit that a later feed overwrote. The CMDB ownership model sets out who may change each ownership attribute, and the ServiceNow Discovery guides explain how scans set values, so you can check which feed wrote the wrong group.
Routing holds up better when ownership follows the service rather than each server. If the group comes from the business service a configuration item supports, a reorganisation changes one record instead of hundreds. For wider service modelling that supports this, CMDB, CSDM and ITAM data ownership covers how accountable owners are set up.
Check the data first, because changing the rule while owners are still wrong usually moves the errors to another queue.
Confirm it at every reorganisation and on a fixed cycle, with each service owner signing off the group for their classes. Stale owners usually surface only when a ticket goes astray.
To improve CMDB accuracy, use the four techniques in a fixed division of labour. Discovery supplies fresh facts, normalization makes those facts comparable, deduplication decides which records are the same thing, and enrichment adds business context that a scan cannot see. Mixing up these jobs is a common reason teams run all four and still find the data wrong.
| Technique | Error it fixes | Error it cannot fix |
|---|---|---|
| Automated discovery | Stale or missing technical facts | Who owns the item, what service it supports |
| Normalization | Same value written several ways, such as vendor or model names | Values that are simply wrong |
| Deduplication | Two records for one real item | Records for items that no longer exist |
| Enrichment | Missing context such as owner, environment, criticality | Wrong technical facts from a bad source |
Standardise the values that take part in identification first, then run the matching.
A discovered server with correct hardware details but no owner, no environment and no linked service is accurate and still useless for a change review.
Automation does not remove the need for a human decision; it moves it. Someone still has to decide which source wins for each attribute and how long a record may go unseen before it is flagged.
A practical check after each pass: take a small sample of records, compare them with the real environment, and note which of the four errors in the table you find most. Fix that one next. The ServiceNow CMDB guides collect the wider topic, and the discovery credential and scope guide explains why a scan that cannot reach a device can leave its record stale. If scanning coverage is the weak point, see discovery consulting.
No. It keeps technical facts current for what it can reach, but ownership, service links and retirement decisions still need a defined source and a person responsible.
A CMDB is judged by whether it can show what depends on what during an outage or a change. An asset inventory is judged by whether it can show what the organisation owns, where it sits and what it is entitled to use. A record can pass one test and fail the other, so the two need separate targets. Treating them as one clean-up project is a common reason an accuracy effort stalls.
In most implementations the CMDB depends on correct configuration items, their classes, their operational status and the relationships between them. The asset register depends on serial numbers, contract terms, entitlements, locations and disposal dates. A laptop can be recorded correctly as an asset and still be missing from the CMDB, because nothing discovered it or because it was never related to the service it supports. If the register is where your gap sits, the IT asset management guides are the place to start.
A practical way to choose which accuracy to chase first is to ask which decision the data will feed:
The common mistake is to load the asset register into the CMDB and assume the two now agree. Duplicate hosts appear under different names, asset tags land in fields that expect something else, and retired hardware often keeps its relationships alive. The fix is to compare the two datasets record by record before trusting either one, and to count the mismatches by type so the largest group is dealt with first. Often the disagreement turns out to be a question of which team is allowed to change a given field.
If leadership relies on the asset register for renewals or audits, treat that register as the first priority. Pairing it with the CMDB is easier once both have owners and a written rule. For teams that need that pairing set up on the platform, ServiceNow asset lifecycle work is the next step.
Before a configuration item is used in a change risk assessment or an incident, check four things on its record: who owns it, whether its state is current, when it was last confirmed, and whether its relationships still point to the services it supports. A record that fails any of these checks should be treated as unverified until someone confirms it.
Start with the owner field. If it is empty, or the named person has moved on, nobody can confirm the record, and a remediation ticket has nowhere correct to go. Next compare the operational state with what monitoring or the asset team shows for the same host. A record that still says the server is in use after it has been retired will send an impact view to the wrong services.
Then check freshness. Ask which source last wrote the record and when. A record that discovery stopped seeing after a credential change looks just as complete as a current one. The question to answer is simple: would the last update still be true today?
Relationships matter most for change and incident work. Confirm the parent service and the dependent CIs with a person. A missing relationship makes the impact view too small, so the approver misses a dependency. A stale relationship shows a service that no longer depends on the CI.
How recent is recent enough depends on the change. A low-risk patch on one host can rely on a record checked this week. A change that touches a shared network or a database cluster needs its relationships confirmed in the same session, not assumed from the last import. Write the threshold into the change procedure so the approver is not making that call alone.
Where a check fails, log it against the CI and send it to the owner. Avoid correcting fields mid-window where you can, because edits made under pressure are hard to trace. For how impact views use these relationships, see CMDB service impact analysis. For how relationships are built from discovered infrastructure, see ServiceNow Service Mapping. For the incident side, see ServiceNow Event Management. Confirm field names and relationship types on your own instance and release, since they vary between versions.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.