OBLYTECH / SERVICENOW CAPABILITY
ServiceNow CMDB data quality and governance that leads to action
Connect quality rules to named owners, remediation work, exceptions and review evidence.
PARTNER DELIVERY — OBLYTECH is a ServiceNow Partner.
Discuss your data-quality priorityServiceNow CMDB data quality is useful when it helps a team make a better service,
change, incident, risk or asset decision. OBLYTECH helps organisations connect quality
rules to named owners, remediation work, exceptions and evidence instead of treating
a score as the outcome.
Measure the data that supports a decision
Start with the decision. A service owner may need reliable relationships for impact
review. An operations team may need current ownership for incident routing. An asset
team may need lifecycle fields that can support the next action. Each decision needs
different data and a different definition of useful quality.
The controls behind useful CMDB quality
Ownership and source responsibility
Name the owner for each important class, field, source and remediation route. When
records disagree, define which source is authoritative and who resolves the conflict.
Ownership should describe the decision the team makes, not only the group receiving a
notification.
Rules, exceptions and remediation
Completeness, correctness, timeliness and uniqueness rules matter only when they lead
to work. Define the queue, correction path, escalation and exception condition. A
reviewable exception is safer than silently lowering a rule or merging records without
understanding their distinction.
Review evidence and improvement
Evidence should show the condition found, the owner, action taken, exception accepted
or rejected, and resulting record state. Review cadence should support improvement,
not create a report that no team uses.
How OBLYTECH approaches CMDB quality
- Identify the operational decision and records it depends on.
- Map owners, sources, classes, relationships and remediation queues.
- Define quality rules, thresholds, exceptions and escalation.
- Test incomplete, duplicate, conflicting and stale records.
- Establish evidence, review cadence and change ownership.
For the wider route, see the ServiceNow services overview.
For the connected platform hub, see ServiceNow CMDB, CSDM and ITAM.
What the engagement can establish
- a decision-led quality scope;
- ownership for sources, classes and remediation;
- actionable rules and exception paths;
- review evidence and improvement cadence; and
- a controlled first release.
Discuss your CMDB data-quality priority
Bring the quality condition that is slowing service decisions: missing ownership,
unclear source authority, duplicate records, weak relationships or stale lifecycle
information. OBLYTECH can help define a control that leads to accountable work.
Discuss your CMDB data-quality priority
Bring the quality condition that is slowing service decisions: missing ownership, unclear source authority, duplicate records or weak relationships.
Discuss your CMDB data-quality priority with OBLYTECHWhy a single quality score misleads the people who read it
A quality score compresses many different conditions into one number. A record with a missing location and a record with a duplicate serial number may both reduce the same total, yet they have different consequences. One blocks a physical audit, the other can send an incident to the wrong team. When a score is the only thing a steering group sees, it tends to rise through cosmetic fixes while the decisions that depend on the data stay unchanged. A more useful report separates quality by the decision each group of records supports, and says which decisions are currently unsafe.
That reframing changes what a threshold is for. A threshold stops being a target for the score and becomes a statement about whether a particular decision can be made from the data as it stands. Setting thresholds this way is slower to agree, but it produces a view that operators will act on.
Matching each quality rule to the decision it protects
The starting question for any rule is which decision would be wrong without it. The table below shows how common rules map to decisions. The examples are typical, and each team should confirm the decisions its own records support.
| Decision that depends on the data | Rules that matter most | What a failing record should trigger |
|---|---|---|
| Routing an incident to the right support group | Current ownership and an accurate support group on the service or configuration item | A remediation task to the owning team, with a deadline agreed with that team |
| Assessing the impact of a planned change | Reviewed relationships between services and the components they run on | A hold on the impact view for that service until the relationships are confirmed |
| Supporting an asset or license review | Lifecycle state, location and a unique identifier | An asset-team queue, separate from the service owner’s queue |
| Reporting service availability | Stable identity for the service and its components | A flag on the affected service report rather than silent correction |
| General reference and search | Completeness of descriptive fields | An advisory item with no escalation |
Rules in the last row are legitimate. They help people find things and they should be measured, but they should not generate the same urgency as a rule that protects an operational decision. Giving every rule equal weight is the quickest way to bury the ones that matter.
Turning a failing rule into work someone finishes
A rule that fails and produces nothing is a report, not a control. Each rule that carries operational weight needs a defined queue, a responsible group, a correction path, an escalation condition and a closure test. The closure test is the part most often missing. Closing a task because someone edited a field is different from closing it because the decision the rule protects is now safe.
- Name the group that corrects the record and confirm it accepted that responsibility.
- Define the correction path, including whether the fix happens in the record, in the source system or in both.
- Set the escalation condition, such as a record that remains failing after a review cycle or a rule that conflicts with another source.
- Write the closure test in terms of the decision, for example that a service now has a confirmed owner who answered a test notification.
Where a source system is authoritative for a field, correcting the record in the platform is often overwritten on the next synchronization. That loop is common and frustrating. The quality work should identify it early and move the fix to the source, or agree a documented exception.
Writing exceptions that a reviewer can understand later
Every quality program ends up with exceptions. Some records are legitimately incomplete for a period, some are intentionally separate from a similar record, and some belong to a system the organization is retiring. A silent exception is dangerous because it removes a problem from view without explaining why. A useful exception records the condition, the reason, the accountable person who accepted it, the review date and the decision it affects.
- Condition: the exact record or class and the rule it does not satisfy.
- Reason: why correcting it now would be worse than leaving it, stated in operational terms.
- Accountable person: a named role that can withdraw the exception, not the name of the rule’s author.
- Review point: a condition that brings the exception back for review, such as a planned retirement or a source change.
Review cadence that changes something
Quality reviews fail when they produce a report that nobody reads or a meeting that repeats the last one. A cadence works when each review ends with a decision on at least one rule: tighten it, relax it with a recorded reason, move it to a different owner, or retire it. The evidence for that decision should show the condition found, the owner, the action taken, whether an exception was accepted or rejected, and the resulting state of the records. Agree the cadence with the owners of the decisions, not only with the data team.
What quality governance cannot fix on its own
Governance rules cannot repair data that discovery never collected. If a class of hosts is not scanned, a quality report will show gaps accurately and still fail to explain why. The discovery and service mapping page addresses discovery as an operating process, and the CMDB class concept explained explains what a CMDB class is.
Quality also depends on who is allowed to decide. Where no one owns a class or a source, the rule has nowhere to send its work. The CMDB ownership model page addresses who decides and who corrects CMDB data, and the reconciliation and duplicate control page addresses the separate subject of reconciliation and duplicates.
Questions to ask before tightening a CMDB quality rule
Should a failing rule block a change request?
Only when the rule protects the decision the change depends on. A missing description rarely justifies a block. A relationship that the impact assessment relies on often does. The safer pattern is to show the warning on the change, name the owner, and require a stated acceptance from someone with authority over the service.
How do we stop quality scores from rising through cosmetic edits?
Measure the decision outcome alongside the score. If incidents still route to the wrong group after a rule passes, the rule is measuring the wrong thing. Review a sample of passing records against the decision they are supposed to support.
Who should set the thresholds?
The owner of the decision should set them, with the data team advising on what can be measured reliably. A threshold chosen by the data team alone tends to reflect what is easy to measure rather than what the operation needs.
What happens when two sources disagree about a field?
The rule should name the authoritative source for that field and the decision it protects. The disagreement itself becomes a work item for the owner of the authoritative source, and the lower-precedence value should be kept as evidence rather than deleted.
If a quality score is rising while the decisions it is meant to support still feel unsafe, start with one decision and the records behind it. Collect the rule set and the most recent examples of a wrong routing or a disputed impact list, so the review begins from real cases.
What CMDB data quality means and the checks that measure it
CMDB data quality is how far configuration records are complete, correct and current enough for the decisions that rely on them. In ServiceNow the usual way to measure it is to check three things for each class: whether required fields are filled in, whether values are valid and unique, and whether a trusted source has confirmed the record recently.
The CMDB Health dashboard groups its checks under completeness, correctness and compliance, and most teams add measures of their own. The table shows what each measure looks for and the failure it catches.
| Measure | Typical check | Failure it catches |
|---|---|---|
| Completeness | Required fields such as owner, support group and operational status are populated | A configuration item that cannot be routed because nobody owns it |
| Correctness | No duplicates, no orphaned items without relationships, values inside valid ranges | Two records for one server splitting its incident history |
| Compliance | Items sit in the intended class with the relationships the model expects | A virtual machine stored as a generic computer, so class reports miss it |
| Freshness | Last discovered date falls inside the interval expected for the class | A retired host that still shows as in service |
Start with a few classes, not the whole CMDB
Measuring every class at once produces a long list that nobody owns. Pick the classes that feed decisions the business already makes, usually business services, servers and the applications that run on them, and widen the scope once their owners accept the results.
Enrichment is not the same as correction
People who search for CMDB data enrichment usually mean adding attributes a record lacks, such as cost centre or business criticality, from a system better placed to know them. Correction means fixing a value that is wrong. Enrichment needs a named source and a rule for which source wins when two disagree. Correction needs an owner who can change the record. Treating them as one task is a common reason an enrichment job overwrites a value someone has just fixed. The data governance and source authority page explains how to settle the authoritative source for each field.
When you are ready to choose figures to track, the CMDB KPIs and metrics guide covers which deserve a place on a dashboard, and the discovery and service mapping page covers keeping the collection behind them healthy.
ServiceNow guides on this topic
Guides from the Oblytech ServiceNow library that explain the practice behind this page.