CMDB Health, Governance & Lifecycle States

Section 1

CMDB Health Scoring

CMDB Health is ServiceNow's built-in system for measuring the quality of CI data. It calculates a health score for each CI based on configured rules, then aggregates scores across CI classes and the entire CMDB to give administrators a data quality dashboard.

Think of CMDB Health like a blood test — it doesn't tell you every detail about a patient, but key metrics (completeness, correctness, compliance) tell you if something is wrong and where to focus remediation effort.

Three Health Score Dimensions

Dimension	What It Measures	Example Failure
Completeness	Are required/important fields populated? Are mandatory relationships present?	A server CI has no "managed_by" value — completeness score drops
Correctness	Are field values valid according to configured rules? Do related CIs exist?	A CI has a "supported_by" group that doesn't exist in the system — correctness fails
Compliance	Does the CI meet governance rules? Is it certified? Is it in an expected state for its class?	A server CI has never been certified by its owner — compliance score is 0

Health Score Calculation

For each CI class, an administrator configures Health Rules that specify:

Inclusion filter — which CIs of this class are included in health scoring (e.g., only Active servers). CIs not matching the filter are excluded from the score calculation entirely.
Field rules — for each important field, what weight does it carry in the score? Is it required, recommended, or optional?
Relationship rules — does this CI class need to have at least one relationship of a certain type?

The final health score for a CI is a weighted average of how many rules it passes. A CI with all required fields populated and all relationships present will score 100. Missing a high-weight required field may drop the score below 50.

⚠

Exam Trap — Inclusion Rules Determine Who Is Scored CIs not matching the inclusion filter are not scored — they don't appear as 0% or failures. They simply aren't counted. This is intentional: you don't want "On Order" servers dragging down the health score when they haven't been deployed yet. Only CIs that should have complete data are included in the health calculation.

📘

Core Concept — Completeness vs. Correctness Failures Completeness failures: a field is empty or a relationship is missing. Fix by populating the missing data. Correctness failures: a field has a value but that value is wrong (e.g., references a nonexistent group, or a date field is in the past by more than expected). Fix by correcting the value or fixing the referenced record. The CMDB Health dashboard shows these separately so you know whether you have a "data gaps" problem or a "bad data" problem.

Section 2

CMDB Workspace Navigation

The CMDB Workspace is the centralized dashboard for monitoring CMDB health, exploring CI data, running queries, and viewing insights. Navigate to it via: All → CMDB → CMDB Workspace (or the CMDB Workspace application shortcut).

🏠 Home Tab

Overview dashboard. Shows overall CMDB health score, recent health trends, top CI classes by population, and quick access to recent activities. Starting point for any CMDB review.

❤ Health Tab

Drill into health scores by CI class. Select a class to see completeness / correctness / compliance scores, which rules are failing, and which individual CIs are bringing the score down.

💡 Insights Tab

AI-driven observations about the CMDB. Highlights anomalies, stale CIs, duplicate candidates, and data drift. Recommends remediation actions based on patterns in CI data.

🔍 Queries Tab

Run and save CMDB queries. Find CIs matching specific criteria, export results, and save queries as named views for reuse. The primary ad-hoc CI lookup tool in Workspace.

Within the Health tab, the click path to investigate a specific failure is: Health Tab → Select CI Class → View Failing Rules → Click a Rule → See failing CIs → Open CI. This path lets you go from "servers have 65% health" all the way to the specific server records that are missing the "managed_by" field.

⚠

Exam Trap — Workspace vs. CMDB Module CMDB Workspace is a separate application/UI from the CMDB module in the navigation menu. The CMDB module (Applications → CMDB) gives you table access to CI lists, relationships, and configuration. CMDB Workspace is the analytics/health monitoring interface. Exam questions that mention "monitoring CMDB data quality" mean CMDB Workspace, not the CMDB module.

Section 3

Lifecycle vs. Operational State

This is one of the most-confused topic areas on the exam. ServiceNow CIs have three related but distinct state fields:

Field	Technical Name	What It Tracks	Who Updates It
Lifecycle Stage	lifecycle_stage	The broad phase of the CI's life (Design, Build, Test, Deploy, Operate, Retire)	Automated (CMDB Data Manager, Change workflows) or manual
Lifecycle Stage Status	lifecycle_stage_status	Where within the current stage the CI is (e.g., within "Operate" stage: Commissioned, Active, Maintenance)	Automated or manual, more granular than stage
Operational Status	operational_status	Current operational health: Operational, Non-Operational, Repair in Progress, DR Standby	Updated by incidents, changes, or Discovery

Real-World Example

A server being onboarded might have:

lifecycle_stage = "Build" (it's being set up)
lifecycle_stage_status = "In Testing" (within Build stage)
operational_status = "Non-Operational" (not yet in production)

After deployment and going live:

lifecycle_stage = "Operate"
lifecycle_stage_status = "Commissioned"
operational_status = "Operational"

During a major incident:

lifecycle_stage stays "Operate" (still in operation phase)
lifecycle_stage_status might change to "Maintenance"
operational_status = "Repair in Progress"

⚠

Exam Trap — Operational State ≠ Lifecycle Stage A CI can be Operationally "Non-Operational" (down for maintenance) while still being in the "Operate" Lifecycle Stage (it hasn't been retired or decommissioned — it's just temporarily unavailable). These fields are independent. The exam frequently tests scenarios where you must identify the correct field to update.

Section 4

CMDB Data Manager

CMDB Data Manager is an automated governance tool that applies lifecycle management policies to CI records at scale. Rather than manually decommissioning thousands of old servers, CMDB Data Manager runs scheduled jobs that evaluate policy conditions and take configured actions.

🧩

Analogy — Estate Lawyer CMDB Data Manager is like an automated estate lawyer. You define the rules in advance: "If a CI has been in Retired state for more than 90 days, archive it. If archived for 365 days, delete it." The lawyer (Data Manager) checks these conditions on a schedule and executes the transitions without human intervention, unless exceptions require review.

Three Policy Actions

Action	What It Does	CI Is Still Accessible?
Retire	Changes CI operational_status to "Retired" / lifecycle_stage to "Retire". The record remains fully visible and queryable in the CMDB.	Yes — full access
Archive	Moves the CI to a separate archive table (`cmdb_ci_archive` or similar). The CI is removed from default list views but can still be found via archive searches.	Limited — requires explicit archive search
Delete	Permanently removes the CI record and its relationships from the database. This action is irreversible.	No — permanently gone

Policy Configuration

Each CMDB Data Manager policy specifies:

Target CI class — which CI type the policy applies to
Condition — filter that CIs must match for the policy to trigger (e.g., operational_status=Retired AND last_discovered older than 90 days)
Action — Retire, Archive, or Delete
Schedule — how often the policy evaluates (daily, weekly)
Task creation — optionally create a task for human review before executing

1

Scheduled Trigger

Policy Runs on Schedule

The CMDB Data Manager policy triggers on its configured schedule (daily, weekly). It queries the target CI class table using the policy's filter condition (e.g., operational_status=Retired AND last_discovered > 90 days ago).

2

Candidate Collection

Matching CIs Collected into Candidate List

All CIs matching the filter are gathered into a candidate batch. If the policy is configured to create review tasks, a task record is generated for each candidate CI and assigned to the designated reviewer.

3

Human Review (Optional)

Reviewer Confirms or Rejects Each Candidate

If review tasks are enabled, a human reviewer evaluates each candidate. They confirm (proceed with action) or reject (exclude from batch). Rejected candidates are not acted on in this cycle.

Confirmed

Proceed to Action

CI is added to the confirmed batch for the lifecycle action.

Rejected

Excluded This Cycle

CI is skipped. Will be re-evaluated on the next scheduled run if it still meets the condition.

4

Action Executed

Retire / Archive / Delete Applied

The policy's configured action is applied to all confirmed candidates. Every action is logged with a timestamp, actor, and CI details for audit purposes.

Retire — sets operational_status=Retired Archive — moves to archive table Delete — permanently removes (irreversible)

🚨

Warning — Delete is Irreversible CMDB Data Manager Delete policies permanently remove CI records. There is no "trash" or "undo." Before creating a Delete policy, always configure a prior Archive policy (archive first, then delete after a longer retention period). This gives a recovery window if a CI is accidentally marked for deletion.

Section 5

CMDB Governance Best Practices

CMDB Governance refers to the policies, processes, and tools that ensure CI data remains accurate, complete, and compliant over time. It's not just technical — it includes organizational ownership and process discipline.

Key Governance Elements

CI ownership — every CI should have a designated owner (managed_by group or owned_by person) responsible for its accuracy
Data Certification — periodic human review of CI data by owners (covered in Part 3)
CMDB Health rules — automated scoring to surface quality issues proactively
Reconciliation Rules — define authoritative sources for each field to prevent data corruption
Change Management integration — all changes to infrastructure should flow through Change Management and update CIs automatically
CMDB Data Manager policies — automated lifecycle transitions to prevent stale data accumulation

📘

Core Concept — Governance is Preventive, Not Reactive Good CMDB governance prevents data quality problems from occurring rather than fixing them after they accumulate. Reconciliation Rules prevent overwrites. Health scoring surfaces issues early. Data Certification catches stale data. Data Manager prevents zombie CIs. Each layer adds a quality control point.

Section 6

Stale CI Detection

A stale CI is a CI record that hasn't been updated or discovered in an unexpectedly long time. If a server CI hasn't been seen by Discovery in 60+ days, it may have been decommissioned without the CMDB being updated.

ServiceNow tracks the last_discovered field (updated each time Discovery finds the CI) and the sys_updated_on field (updated on any modification). CMDB Health rules and CMDB Data Manager policies can use these fields as staleness indicators.

A common health rule: flag any server CI with last_discovered older than 90 days
A common Data Manager policy: retire any CI flagged as stale for 30+ days
CMDB Workspace Insights tab surfaces stale CI candidates automatically

Exam Quick Reference

Common Exam Traps — CMDB Health, Governance & Lifecycle

Health score = weighted average of rules passed (completeness + correctness + compliance)
Inclusion filter = which CIs are scored; CIs outside filter are NOT counted (not 0%)
Completeness = empty fields; Correctness = values exist but are invalid
CMDB Workspace tabs: Home (overview), Health (drill into scores), Insights (AI observations), Queries (ad-hoc CI lookup)
lifecycle_stage = broad phase (Design/Build/Test/Operate/Retire)
lifecycle_stage_status = within-phase status (Commissioned/Maintenance/Decommissioned)
operational_status = real-time health (Operational/Non-Operational/Repair in Progress)
A CI can be Non-Operational while still in Operate lifecycle stage
CMDB Data Manager: Retire (status change only) → Archive (removed from default views) → Delete (permanent)
Delete is irreversible — always archive before configuring a delete policy

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

CMDB Health & Governance Quiz 1 / 4

A CMDB Health rule requires that all server CIs have a non-empty "owned_by" field. 300 of the 500 servers in scope have owned_by populated. What is the health score for this rule?

💡 Explanation

B is correct. CMDB Health scoring is a percentage of CIs that pass the rule within the scope of the inclusion filter. 300 out of 500 servers have owned_by populated, so the score is 300/500 = 60%. The health score reflects compliance rate, not a binary pass/fail. This percentage then feeds into the overall weighted CMDB Health score across all rules. Improving the score means getting more CIs to comply with the rules.