Discovery
CMDB Data Correctness
Identify duplicate records, stale CIs, and orphaned assets across every CI type — the final data quality check before migration execution.
Overview
CMDB Data Correctness goes beyond field completeness to check the integrity of your data. It identifies three categories of issues across all CI types (Applications, Devices, Databases, Hosts, Networks):
Duplicates
Records that appear more than once — typically from multiple integration imports.
Stale Records
CIs not updated within a configurable threshold (default: 90 days).
Orphaned CIs
Records missing required relationships — e.g. a device with no associated host.
This screen is visible to Administrators only.
When to Use
- After running multiple integration imports — duplicates are common when the same VM appears in both VMware and Nutanix sources
- Before finalising move groups — stale or orphaned devices will cause errors during execution
- As part of a monthly CMDB health review
- When the overall quality score in Device or Application Data Quality is unexpectedly low
Dashboard Sections
| Section | What it shows |
|---|---|
| KPI Cards | Overall correctness percentage, number of CI types tracked, total duplicate count, total stale + orphaned count. |
| Correctness by CI Type | Stacked bar chart showing the mix of duplication, staleness, and orphaned issues per CI category. |
| Stale Threshold Control | Adjustable slider/input to change the "days since last update" threshold that marks a record as stale. Changing this refreshes the metrics live. |
| CI Type Breakdown Table | One row per CI type (Application, Device, Database, Host, Network) showing: Total, Duplicate Count, Stale Count, Orphaned Count. |
How to Use
1
Navigate to Discovery → Data Quality & Discovery → CMDB Data Correctness.
2
Check the overall correctness % KPI. Aim for above 90% before migration execution. Below 80% indicates significant integrity issues.
3
Review the CI Type Breakdown table. Find CI types with the highest duplicate counts. Navigate to the corresponding CMDB list and merge or delete the duplicates.
4
Adjust the Stale Threshold to match your project's data currency requirement (e.g. 30 days for an active migration). Review which records fall outside this window and decide whether to refresh them or mark them out of scope.
5
For orphaned CIs, navigate to the affected CI list, open each record, and link it to its parent (e.g. assign a host to an orphaned device).
Key Fields
| Field | Description |
|---|---|
| Overall Correctness % | Weighted score across all CI types reflecting the proportion of clean records. |
| CI Type | Category of configuration item: Application, Device, Database, Host, Network. |
| Total Count | Total records of this CI type in the CMDB. |
| Duplicate Count | Records sharing the same name or key identifier as another record of the same type. |
| Stale Count | Records not updated within the stale threshold period. |
| Orphaned Count | Records missing a required relationship (e.g. device with no host, application with no owner). |
| Stale Threshold (days) | Configurable number of days. Records not updated within this window are flagged as stale. |
Issue Types Explained
| Issue | Cause | Resolution |
|---|---|---|
| Duplicate | Same CI imported from multiple sources (e.g. a VM present in both RVTools and a CSV export). | Open the CMDB list, identify the duplicate pair, retain the richer record, and delete the other. Consider using the import merge option on next sync. |
| Stale | Record has not been updated or re-imported within the threshold period. May indicate the CI has been decommissioned or is no longer monitored. | Re-run the integration import to refresh, or manually update the record. If the device is gone, mark it Out of Scope and archive. |
| Orphaned | CI exists without a required parent relationship — e.g. a device not linked to a host/cluster, or an application without an owner. | Open the record and assign the missing relationship. For bulk orphans, use a CSV update import. |
Tips & Common Mistakes
Run this check immediately after every integration import. Duplicates created during import are much easier to resolve immediately than after move groups have been built.
Set the stale threshold to match your integration sync frequency. If you import weekly, a 14-day threshold will quickly flag anything that missed a sync cycle.
Deleting duplicate records is permanent. Always confirm which record has the most complete data before deleting. If in doubt, export both records first.
A high orphaned count for Devices often means your host/cluster data was imported separately and the linking step was skipped. Re-run the VMware or Nutanix integration with the host mapping option enabled.