CMDB Health Dashboard — Completeness 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: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Overview Are your CIs showing as unhealthy under the Completeness metric on the CMDB Health Dashboard? Are you unsure why certain CIs are flagged or why certain classes are not being evaluated at all? This article explains exactly how the Completeness score works — where fields come from, how CIs are evaluated, what causes failures, and which tables to check when something does not look right. This article covers: What the Completeness metric is made ofWhere required and recommended fields come fromHow the processing runsWhich CI classes get evaluated and why some get skippedWhat makes a CI failWhich tables are involvedWhat to check when results seem wrong or stuck ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ What Is the Completeness Metric Completeness is a parent metric made up of two independent sub-metrics: Required Fields — checks if fields that are mandatory on the CI class schema are populatedRecommended Fields — checks if fields configured in cmdb_recommended_fields for a CI class are populated Both run independently on a schedule. The overall Completeness score is derived from the combined results of both. ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Where Do Required and Recommended Fields Come From This is the most important thing to understand before troubleshooting any completeness issue. Required Fields No separate configuration table — required fields are read directly from the CI class schemaAny field where the mandatory flag is set on the CI class or its parent classes is treated as a required fieldsys_id is always excluded even if marked mandatoryNot customer configurable via a table — controlled purely by the field's mandatory attribute in the schema Recommended Fields Stored in the cmdb_recommended_fields table — fully customer configurableEach record has two key fields — table (the CI class) and recommended (comma separated list of field names)If no record exists for the exact CI class the system walks up the class hierarchy to find a parent class recordIf nothing is found anywhere in the hierarchy the class is skipped — no failures generatedThis means child classes automatically inherit recommended field configuration from their parent class ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Which CI Classes Get Evaluated Before processing starts the system builds a list of CI classes to evaluate: Queries cmdb_ci grouped by sys_class_name to find all classes with at least one recordOnly classes whose absolute base table is cmdb_ci are includedInvalid class names are skipped and logged as warnings This list is then filtered by two configurations: Health Metric Qualifier (sn_cmdb_ws_health_metric_qualifier) System checks if the table exists and has rows — if not all classes pass through without filteringIf it has rows only classes configured in that table for the metric are includedEach record has class_name, metric, type (include or exclude), and apply_to_childrenIf apply_to_children is true the rule also applies to all child classes in the hierarchyRules are processed in hierarchical order — more specific child class rules take precedence Health Config Active Record Condition (cmdb_health_config) If a Health Config record exists for a CI class for this metric an encoded query condition is appliedOnly CIs that meet that condition are evaluated — the rest are excludedIf no Health Config record exists for a CI class all CIs of that class are evaluated ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ How Required Fields Sub-Metric Works Reads CI class schema — collects all fields where mandatory flag is set, excluding sys_idIf no mandatory fields found — batch marked as skipped in cmdb_health_processor_status, no failures generatedQueries the CI class table with strict class match (sys_class_name = class being processed — no hierarchy traversal)OR condition applied across all required fields — at least one must be empty for CI to be returnedHealth Config condition applied if configured via cmdb_health_configIf run was interrupted — resumes from last sys_id stored in cmdb_health_processor_statusFor each CI returned — checks every required field individually and builds list of which ones are emptyCreates failure record in cmdb_health_result with description: Following required fields are not populated followed by field names ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ How Recommended Fields Sub-Metric Works Same as Required except these key differences: Looks up cmdb_recommended_fields for the CI classIf no record found — walks up class hierarchy to find parent class recordIf still nothing found — batch marked as skipped, no failures generatedFor each CI returned — checks every recommended field from cmdb_recommended_fields and builds list of which ones are emptyCreates failure record in cmdb_health_result with description: Following recommended fields are not populated: followed by field names ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ What Makes a CI Fail Completeness Even one empty required or recommended field on a CI generates a failure recordThe failure record in cmdb_health_result tells you exactly which fields are missingA CI can appear in both Required and Recommended failures at the same time if both types of fields are missing ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ What Can Prevent a CI From Being Evaluated No mandatory fields on the CI class schema — Required sub-metric skips the classNo record in cmdb_recommended_fields for the class or any parent class — Recommended sub-metric skips the classClass excluded via sn_cmdb_ws_health_metric_qualifierCI does not meet the Health Config active record condition in cmdb_health_configClass has no CI records in cmdb_ci — empty classes not included in the batchCompleteness metric or sub-metric is marked inactive — no batches loaded, no processing runs ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Important Tables cmdb_ci Base CI tableQueried to build list of CI classes to evaluate grouped by sys_class_name cmdb_recommended_fields Stores recommended field configuration per CI classKey fields: table (CI class name), recommended (comma separated field names)Customer configurable — child classes inherit from parent class if no specific record exists cmdb_health_config Stores active record condition per CI class per metricControls which CIs within a class are in scope for evaluation sn_cmdb_ws_health_metric_qualifier Stores include and exclude qualifier rules per CI class per metricKey fields: class_name, metric, type, apply_to_childrenOnly used if table exists and has rows cmdb_health_result Stores individual failure records per CI per metricDescription field contains exact list of missing fieldsRecords marked to_delete = true at start of each new run cmdb_health_result_count Stores aggregated failure counts per metricCleared at start of each new run and rebuilt as run completes cmdb_health_metric_status Tracks run status per metric and sub-metricKey fields: metric, status, started_on, run_time, activeStatus values: IN_PROGRESS, COMPLETE, TIME_OUT, MAX_FAILURES, NOT_RUNFirst table to check when a run appears stuck cmdb_health_processor_status Tracks processing status per CI class batch per metricKey fields: batch_name, metric, last_processed_id, status, skippedBatch status values: DRAFT, IN_PROGRESS, COMPLETElast_processed_id enables resumable processing ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Key Things to Remember Completeness = Required Fields + Recommended Fields — both must complete for full pictureRequired fields come from CI class schema mandatory flag — not a configurable tableRecommended fields are customer configurable via cmdb_recommended_fields — child classes inherit from parentOne empty field on a CI is enough to flag it as a failureClasses with no mandatory schema fields or no cmdb_recommended_fields record are skipped automaticallyHealth Config (cmdb_health_config) controls which CIs within a class are in scopeHealth Metric Qualifier (sn_cmdb_ws_health_metric_qualifier) controls which CI classes are in scopeResults refreshed on every run — old results marked to_delete before new ones writtenStuck runs auto cleaned up based on glide.cmdb.health.max.inactivity.period (default 1 day) ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ Related Tables Tables: cmdb_cicmdb_recommended_fieldscmdb_health_configsn_cmdb_ws_health_metric_qualifiercmdb_health_metric_statuscmdb_health_processor_statuscmdb_health_resultcmdb_health_result_count