CMDB Health Dashboard — Correctness KPI: What Runs, How It Works, How CIs Are Evaluated, What's Stored, and Where to VerifySummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Ever wondered how CMDB Health Correctness decides whether your data is "right"? It starts when the scheduled job "CMDB Health Dashboard - Correctness Score Calculation" evaluates the in-scope CI set-->applies your inclusion rules-->computes three sub-metrics—Staleness, Orphan, and Duplicate -- before rolling them up into the Correctness KPI you see on the CMDB Health dashboard. What "Correctness" includes → Correctness is an aggregate KPI built from three sub-metrics: Staleness, Orphan, and Duplicate (each scored per-CI, then rolled up). When and how the evaluation runs →A scheduled CMDB Health job evaluates each sub-metric and writes CI-level "health results," then activates scores and cleans up rows marked for removal. Exactly when a CI is marked Stale → A class-specific Staleness rule (with inheritance) supplies an Effective Duration. Any CI whose last update time is older than now − Effective Duration is flagged as Stale. → The engine evaluates only CIs that meet your Health Configuration(cmdb_health_config) "Active record" condition for that metric/class; others are excluded from consideration. → Optional behavior: set glide.cmdb.health.staleness_exclude_dependent_cis to true to skip dependent CI types during staleness evaluation. → Staleness evaluations are scanned in batches of 1000 CIs for throughput (internal behavior; visible only as faster runs). → Documentation note: a default 60-day rule for cmdb_ci exists in base content and can be overridden per class. Exactly when a CI is marked Orphan → The evaluation uses an Orphan rule for the class (with inheritance). A CI is Orphan when it matches the rule’s condition, and/or when the rule's "no relationship" requirement is set and the CI has no relationships. → Only CIs that satisfy the Health Configuration(cmdb_health_config) "Active record" condition for the metric/class are included. → Orphan evaluations are processed in batches of 1000 CIs (for progress and resilience on long-running scans). Exactly when a CI is marked Duplicate → Duplicate checks are applied to classes whose Identification Rules are "independent"; dependent classes are skipped. → Candidate CIs are those with discovery_source = Unknown and sys_updated_on within the last day, or with empty discovery_source. These candidates are then audited by the Identification Engine to detect duplicates (This evaluation is from the scheduled job. For more details on this logic please visit KB0726425). → CIs already marked duplicate by the Identification Engine are filtered out of the candidate list to avoid re-flagging. → The Health Configuration(cmdb_health_config) "Active record" condition (per metric/class) further limits which candidates are evaluated. Which CIs are included (Inclusion rule) → Before any result is created/updated, a Health Configuration record(cmdb_health_config) (per metric/class, with inheritance) supplies an encoded query used as a pre-filter for the CI set. Only CIs that pass this filter are evaluated for that sub-metric. Health configuration & rule tables → CMDB Health Configurations : Active record conditions and rule tables — Health Configuration (with inheritance), cmdb_health_staleness_rule, and cmdb_health_orphan_rule determine which CIs participate in Correctness and what thresholds/logic apply. → Health Configuration (cmdb_health_config) stores an active_record_condition per metric and class; at run time the platform resolves the most-specific config via class inheritance and applies that encoded query to each CI to decide inclusion. If no config exists, the CI is considered included. → Staleness rules (cmdb_health_staleness_rule) define the applies_to class and duration (how "old" is stale); the engine looks up the rule for the CI's class (and domain), then uses that duration when evaluating staleness. → Orphan rules (cmdb_health_orphan_rule) carry the class, condition, optional filter, and no_relationship flags used to decide when a CI is orphaned (for example, "no relationships of required types" + optional additional filters). → Inclusion rules and metric rules are cached for performance; caches exist for health config, staleness, and orphan rules, so updates flow through those caches. → Admin tip (UI): You can define/maintain health inclusion rules per class (with inheritance) from CI Class Manager → Health → Health Inclusion Rules; these are the same Active record conditions the engine evaluates. Discovery vs CMDB Health sources (Staleness) → Discovery may independently mark items (for example, vCenter CIs that no longer exist) as Stale; these appear with Source like Discovery. To have your Correctness KPI aggregate only CMDB Health results (while drill-downs can still show Discovery source), set glide.cmdb.health.src.cmdb_health_audit_only = true. Where results are stored and how lifecycle flags work → CI-level findings are persisted in cmdb_health_result with fields such as ci, class_name, metric (Staleness/Orphan/Duplicate), source, last_evaluated_on, description/failure_description, active, and to_delete. Active results reflect the latest evaluation; rows marked to_delete = true are removed at the end of the cycle. → After processing and score activation, rows still marked to_delete are deleted; this is the expected cleanup step each cycle. Ownership stamping (who "owns" the fix) → The field used for result ownership is configurable; by default, ownership is stamped from the CI's managed_by_group. To change it, set glide.cmdb.health.ci_ownership_field to the CI field name you want used. (This affects the owner stamped on new/updated results.) How counts and scores are produced → Per-metric failure counts may be cached to cmdb_health_result_count for faster dashboards.→ The run then activates scores and metric statuses for the Correctness parent and its children; finally, it deletes all rows still marked to_delete. Verify CMDB-wide, service, and group scores in the cmdb_health_scorecard tables. Tables you will use to verify every stage → cmdb_health_result — the per-CI findings for Staleness, Orphan, Duplicate; check active, to_delete, source, last_evaluated_on, and ownership.→ cmdb_health_result_service_map / cmdb_health_result_group_map — which CI-level results roll up to which services or groups.→ cmdb_health_result_count — optional aggregated counts used by dashboards during/after a run.→ cmdb_health_scorecard, cmdb_health_scorecard_service, cmdb_health_scorecard_group — KPI rollups and statuses; confirm totals, failed, score, status. Typical verification path → After a run, new/ongoing findings in cmdb_health_result show fresh last_evaluated_on, active = true, to_delete = false.→ Service/group drill-downs reflect updated mappings; scorecards reflect updated counts/scores. Rows left with to_delete = true are removed during cleanup. Key properties to know → glide.cmdb.health.ci_ownership_field — CI field used as result owner (default managed_by_group). → glide.cmdb.health.staleness_exclude_dependent_cis — when true, excludes dependent CI types from staleness evaluation. → glide.cmdb.health.src.cmdb_health_audit_only — when true, Correctness KPI aggregates only CMDB Health results (Discovery can still appear as the per-CI source in drill-downs). Takeaways → Staleness = CI not updated within the Effective Duration from the class rule; optional skip for dependent CIs; inclusion rule applies first. → Orphan = CI satisfies the orphan condition and/or has no relationships per its class rule; inclusion rule applies first. → Duplicate = CI in independent class, candidate by Unknown/empty discovery_source and recent update, confirmed by Identification Engine audit; already-marked duplicates are ignored; inclusion rule applies. → Results live in cmdb_health_result with lifecycle flags; scores activate at run end; stale rows get deleted as part of the normal cleanup.