← All guides

7 Data Quality Rules That Will Transform Your ServiceNow CMDB

SN-Tricks /

Learn the 7 data quality rules that separate a healthy CMDB from a bloated, unreliable one. Practical steps for ServiceNow ITSM and ITOM admins.

The Configuration Management Database (CMDB) is the backbone of ITSM in ServiceNow. Every incident, every change request, every problem investigation depends on it. And yet, most organizations treat it like a data dumping ground — full of duplicate records, stale relationships, and CIs that haven't been updated since 2019.

A bad CMDB isn't just annoying. It actively hurts your ITSM outcomes. Impact analysis becomes a guessing game. Change advisory boards lose confidence. Performance Analytics dashboards show garbage.

Here's how to fix that. These 7 rules will keep your CMDB healthy, accurate, and genuinely useful.

Rule 1: One CI, One Record — No Exceptions

The single most common CMDB problem is duplicate configuration items. Same server, three records. Same application, five entries with slightly different names.

Duplicates break impact analysis. When an incident fires on "web-prod-03," the system may only resolve one of the records, missing half the affected services.

How to fix it:

  • Enable CI Unique ID enforcement in the CMDB properties. This prevents duplicate inserts based on a defined key (hostname, IP, serial number).
  • Run regular deduplication reports using the CmdbCiDuplicate table or a scheduled report.
  • Establish a Discovery-first policy: any new CI should come from Discovery or ServiceNow IntegrationHub before manual creation is allowed.
// Example: Find duplicate CIs by host name in GlideRecord
var gr = new GlideRecord('cmdb_ci');
gr.addAggregate('COUNT', 'name');
gr.addQuery('name', '!=', '');
gr.addHaving('COUNT', 'name', '>', '1');
gr.query();
while (gr.next()) {
    gs.info('Duplicate CI: ' + gr.name);
}

Rule 2: Classify CIs Correctly — Use the Right CMDB Class

CMDB class hierarchy exists for a reason. A CI's class determines what fields are available, how relationships are visualized, and what data appears in Discovery results. Misclassifying a CI — calling a virtual machine a "hardware server," for example — breaks relationship mapping.

How to fix it:

  • Document your organization's CMDB class model and make it accessible to anyone creating CIs.
  • Use Reference Qualifiers on forms to limit which classes are available for selection based on the user's role or business unit.
  • During Discovery runs, verify that detected CIs are being classified correctly. Tune classifiers if they're misrouting.

Rule 3: Keep Relationships Accurate and Meaningful

CIs without relationships are isolated islands. They don't support impact analysis, they don't populate the ServiceNow Dependency View, and they make Change Management's job nearly impossible.

Every significant CI should have at least one of: hosted on, runs on, depends on, used by, or network relationship.

How to fix it:

  • Make relationship creation part of your Discovery schedule — ensure MID server runs populate not just CIs but their logical connections.
  • After any major change (new server, new application deployment), require relationship updates in the change ticket.
  • Audit existing relationships quarterly. Use the relationship analysis report to find CIs with zero relationships — these are your top cleanup candidates.

Rule 4: Populate the Critical Fields — Especially for Business Services

Not all fields are equal. The most critical fields for ITSM workflows are:

  • Name (unique identifier)
  • Class (correct CMDB class)
  • Assignment group (who owns it)
  • Environment (Production, Test, Dev)
  • Support group and Lifecycle stage
  • Business criticality for Business Services

A CI with a name but no assignment group is nearly useless during an incident.

How to fix it:

  • Set fields as mandatory in the CMDB table definitions for high-priority classes (cmdb_ci_server, cmdb_ci_service_discipline).
  • Create a CMDB Data Quality Dashboard using Performance Analytics or reporting to track fill rates per field.
  • Prioritize business service CIs — these drive incident prioritization and are most visible to leadership.

Rule 5: Decommission Stale CIs Promptly

Stale CIs are a silent killer. A server that was decommissioned two years ago but still appears in your CMDB creates false positives in impact analysis. Change Management approves a change thinking it's low-risk, and the "decommissioned" server is actually still running a critical dependency.

How to fix it:

  • Set a Retire date on any CI that is taken out of service. Don't delete it — ServiceNow's CMDB keeps historical state for auditing.
  • Schedule a quarterly stale CI review: find CIs with no Discovery updates in 90+ days and no recent incidents or changes associated with them.
  • Use the CMDB Health Dashboard to surface CIs with stale data or missing retirement dates.
// Find CIs not updated in 90 days (excluding retired)
var gr = new GlideRecord('cmdb_ci');
gr.addQuery('u_retire_date', '');
gr.addNotNullQuery('sys_updated_on');
var ninetyDaysAgo = new GlideDateTime();
ninetyDaysAgo.setDaysAgo(90);
gr.addCondition('sys_updated_on', '<', ninetyDaysAgo);
gr.query();
gs.info('Stale CIs found: ' + gr.getRowCount());

Rule 6: Sync CMDB with Your Change and Incident Processes

The CMDB is not a standalone database. It needs to be in sync with your change management and incident processes to stay accurate. Every change that affects infrastructure should update the CMDB as a direct output.

How to fix it:

  • Add a CMDB update task as a mandatory step in your Change workflow. The CAB approval should include a requirement that the requester update or confirm CI and relationship data.
  • During incident resolution, if the fix involved modifying or restarting a CI, require that the CI's operational status be updated.
  • Use Flow Designer to auto-update CI status based on incident state changes. When an incident is resolved and the affected CI was restarted, the CI's operational status should reflect that.

Rule 7: Trust but Verify — Use Discovery as Your Source of Truth

Discovery exists so you don't have to maintain the CMDB manually. MID servers scanning your infrastructure should be the primary source of truth for server, network, and cloud CIs. Manual entries should be the exception, not the rule.

How to enforce this:

  • Run Discovery on a regular schedule — weekly for dynamic environments, bi-weekly for stable ones.
  • Compare Discovery results against manual entries. Flag discrepancies for review rather than automatically overwriting.
  • Use ServiceNow VictorOps or integration with your cloud providers (AWS, Azure, GCP) for real-time CI synchronization.

Measuring CMDB Health

ServiceNow provides a built-in CMDB Health Dashboard (CMDB > Health Dashboard) that scores your CMDB across five dimensions:

  1. Completeness — Are required fields populated?
  2. Uniqueness — Are there duplicate CIs?
  3. Relationship Quality — Do CIs have meaningful relationships?
  4. Timeliness — How recently were CIs updated?
  5. Consistency — Does data follow defined formats and standards?

Use this dashboard to set quarterly improvement goals. A jump from 65% to 80% health score will measurably improve your ITSM outcomes.

Final Thoughts

The CMDB is only as good as the discipline you apply to it. These seven rules aren't complex, but they require consistent process discipline — especially around Discovery schedules, change-to-CMDB updates, and regular audits.

Pick one rule, implement it this week, and measure the impact. Your incident response team will notice the difference before the quarter ends.

More practical ServiceNow notes.

Back to the guides