CMDB Health Dashboard — Completeness, Compliance & Correctness
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Building a Trusted and Reliable CMDB in ServiceNow
In today’s digital enterprise, the CMDB is not just a technical database — it is a strategic foundation for IT operations. Incident routing, change risk analysis, impact assessment, service mapping, automation, audits, and governance all depend on accurate configuration data.
Within ServiceNow, the CMDB Health Dashboard provides a structured way to measure and improve CMDB data quality through three core scorecards:
Completeness
Compliance
Correctness
Together, these metrics ensure your CMDB is not only populated — but reliable.
Completeness Scorecard
Are Your CIs Fully Populated?
Why Completeness Matters
A CI missing critical information can disrupt operations.
Imagine an Incident referencing a server CI that does not have:
Support Group
Owner
Location
Cost Center
Change Group
The Service Desk cannot route properly. Tickets bounce between teams. SLAs are breached. Trust in the CMDB decreases.
Completeness ensures that key attributes are populated.
What the Completeness Scorecard Measures
The Completeness KPI aggregates:
Required Attributes
Recommended Attributes
It provides visibility into:
Missing fields by class
Missing fields by owner
Missing fields by discovery source
Overall completeness percentage
This is especially important when populating CIs through:
ServiceNow Discovery
Service Graph Connectors
IntegrationHub ETL
Third-party imports (SCCM, etc.)
Required vs Recommended Fields
Required Fields
Enforced at database level
CI insert fails if empty
Controlled by system property:
glide.required.attribute.enabled = true
Risk: Making too many fields mandatory can break discovery and integrations.
Recommended Fields
Not enforced at DB level
Do not block inserts
Provide governance visibility
Best Practice: Start with Recommended fields before enforcing Required fields.
How to Configure Completeness
Define Required fields via Dictionary Entry or Dictionary Override
Define Recommended fields via CI Class Manager → Health → Completeness
Run:
CMDB Health Dashboard – Completeness Score Calculation job
Review results in:
cmdb_health_metric_status.list
Compliance Scorecard
Are Your CIs Meeting Governance Standards?
Completeness ensures data exists.
Compliance ensures data meets defined standards.
The Compliance Scorecard evaluates whether CIs pass Desired State audits.
What Is Compliance in CMDB?
Compliance compares actual CI values against expected values defined in:
Certification Templates
Scripted Audits
Examples:
All production servers must have an owner
All Windows servers must have antivirus installed
All Linux servers must be on the latest patch
All critical applications must have an assigned support group
If a CI fails any applicable audit, it impacts the Compliance score.
Key Components of Compliance
Certification Filter
Defines the scope of CIs to audit.
Example:
All Windows Servers
All UNIX servers in Datacenter A
Certification Template
Defines expected conditions.
Example:
RAM must be greater than 8GB
Owner must not be empty
Antivirus relationship must exist
Important: Audit type must be Desired State for inclusion in CMDB Health.
Audit Record
Runs the template against the filter.
Scheduled (daily, weekly, etc.)
Can generate remediation tasks
Compliance Score Calculation Job
Navigate to:
Configuration → Health Preferences → Scheduled Jobs
Run:
CMDB Health Dashboard – Compliance Score Calculation
Scripted Audits
If template conditions are not flexible enough, use Scripted Audits.
Navigate to:
Compliance → Desired State → Scripted Audits
Scripted audits allow:
Custom logic
Relationship validation
Complex evaluation rules
Business Benefits of Compliance
Enforces governance standards
Supports audit readiness
Improves upgrade planning
Reduces operational risk
Ensures policy alignment
Correctness Scorecard
Is Your CMDB Accurate?
Correctness measures whether CIs are:
Non-duplicate
Properly related
Up-to-date
It evaluates three metrics:
Duplicate CIs
Orphan CIs
Stale CIs
Duplicate Metric
Duplicate CIs are identified using Identification Rules.
When the Correctness job runs:
The oldest CI remains primary
Newer duplicates are flagged
De-duplication tasks may be created
This helps answer:
Which discovery source creates duplicates?
Which classes have highest duplication?
Orphan Metric
Orphan CIs lack required relationships.
Examples:
Application not running on any server
VM not related to ESX host
Hardware device with no owner
Orphan rules must be configured manually — base system has none.
Only one orphan rule per class is allowed.
Staleness Metric
Stale CIs are those not updated within a defined timeframe.
Base system rule:
CI is stale if not updated in 60 days
Update is based on:
Best Practice:
Customize staleness by class
Network devices (21 days)
Servers (7 days if discovered daily)
Staleness impacts:
Impact analysis accuracy
Change risk evaluation
Lifecycle management
Running the Correctness Job
Navigate to:
CMDB Health Dashboard → Scheduled Jobs
Run:
CMDB Health Dashboard – Correctness Score Calculation
Review results by class and metric.
How the Three Scorecards Work Together
| Completeness | Attribute population | Are key fields filled? |
| Compliance | Policy enforcement | Do CIs meet standards? |
| Correctness | Data accuracy | Is data reliable? |
A CMDB can be:
Complete but incorrect
Correct but non-compliant
Compliant but incomplete
True CMDB maturity requires all three.
