Data Certification & Asset-CI Lifecycle

Section 1

What Is Data Certification?

Data in the CMDB goes stale. Servers get decommissioned but their CI records persist. Ownership changes without updating the CMDB. Services get renamed. Without a process to periodically validate data, the CMDB slowly becomes a historical snapshot rather than a live source of truth.

Data Certification is a scheduled workflow built into ServiceNow that selects a set of records, sends them to designated certifiers (usually business owners or IT managers), and asks them to confirm each record is accurate or flag it for correction. Think of it as an audit cycle run directly within ServiceNow.

🧩

Analogy — Annual Tax Review Data Certification is like asking your accountant to review last year's expenses and mark which ones are still active vs. closed. The accountant doesn't update the data themselves — they mark "confirm" or "needs correction" and someone else acts on the flags. The value is forcing human review on a schedule, not just trusting automated imports.

Key Tables

cert_cert — Certification definition (rule: what to certify, who certifies, schedule)
cert_certifier — Certifier record linking a user to a certification
cert_result — Individual result record for each record in the certification batch

Section 2

Data Certification Workflow

1

Configuration

Define the Certification

An admin creates a Certification record specifying: the target table (e.g., cmdb_ci_server), a filter condition (which CIs to include), the certifier assignment method (by CI owner, by group, or specific user), and how frequently the certification runs.

2

Scheduled Run

Certification Generates Review Tasks

On the scheduled date, the system queries the target table with the filter, creates a cert_result record for each matching CI, and assigns review tasks to the designated certifiers.

3

Human Review

Certifier Reviews Each Record

Certifiers open their assigned tasks and review each CI's data for accuracy. For each record they select an outcome:

Certified

Data Is Correct

Certifier confirms the CI data is accurate. Record marked Certified — contributes positively to CMDB Health score.

Rejected

Data Needs Updating

Certifier marks the record Rejected with a reason. Does NOT update the CI data directly — triggers remediation step.

4

Remediation

Rejected Records Trigger Fix Tasks

Rejected certification records can automatically trigger change requests or tasks to correct the underlying CI data. Certification only marks records — it does not modify CI field values itself. The rejection reason guides the correction.

5

Health Impact

CMDB Health Score Updated

Certified records contribute positively to CMDB Health completeness and compliance dimensions. Uncertified or expired certifications lower health scores. This creates an ongoing incentive to keep certifications current.

⚠

Exam Trap — Certification Does Not Update Data Data Certification only marks records as verified by a human. It does not update field values. If a certifier rejects a record, the CI data stays unchanged until a separate task or change is raised to fix it. Certification is a quality tracking process, not a data correction process.

Section 3

Asset vs. CI — Two Records, One Physical Item

This is one of the most tested concepts in CIS-DF. When you buy a server, ServiceNow creates two separate records:

An Asset record in the alm_asset table — tracks financial and lifecycle information
A CI record in cmdb_ci_server (or another CI class) — tracks technical configuration

These two records are linked. The Asset record has a ci reference field pointing to the CI. The CI record has an asset reference field pointing back to the Asset. They represent the same physical object but from two different perspectives.

🧩

Analogy — Car Title vs. Repair Manual An Asset record is like the car title: who owns it, when purchased, purchase price, warranty, insurance. A CI record is like the repair manual's entry: make, model, VIN, engine specs, current mileage, what's been modified. Same car, two documents, each serving a different audience — Finance vs. IT Operations.

What Each Record Tracks

Attribute	Asset (alm_asset)	CI (cmdb_ci)
Primary audience	Finance, Procurement, HR	IT Operations, ITSM
Cost / depreciation	✓ Tracked	Not tracked
Assigned to (person)	✓ Tracked (who has it)	Sometimes (operational ownership)
Managed by (group)	Sometimes	✓ Primary field
Serial number	✓ Primary identifier	✓ Also stored
IP address / OS	Not tracked	✓ Tracked
Relationships (runs on / depends on)	Not tracked	✓ cmdb_rel_ci
Lifecycle state	On Order → In Stock → In Use → Retired	Installed → Configured → Active → Decommissioned

Section 4

Asset vs. CI Reconciliation

Because Asset and CI records are separate, they can get out of sync. An asset may be marked "In Stock" while its CI says it's actively used. A CI may be discovered on the network (Discovery creates/updates it) while no corresponding Asset record exists.

Sync Mechanisms

ServiceNow uses Asset-CI field synchronization rules to keep certain shared fields consistent between the two records. For example:

Serial number — updated on one record auto-propagates to the other
Assigned to — depending on configuration, asset assignment can sync to CI or vice versa
Name changes on the CI can update the Asset display name

Asset-CI Reconciliation Scenarios

Asset-CI Reconciliation specifically addresses scenarios where the two records diverge:

Discovery finds CI with no Asset — IRE creates/updates the CI; a business rule may auto-create an Asset record and link it
Procurement creates Asset with no CI — Asset record exists in On Order state; when deployed and discovered, IRE creates the CI and the link is established
Lifecycle state mismatch — Asset is "Retired" but CI is still Active. Data Certification or a reconciliation job should flag this

📘

Core Concept — Authoritative Source Per Field IRE reconciliation rules designate which data source is authoritative for each field on a CI. For technical fields (IP address, OS version), Discovery is typically authoritative. For financial fields on the Asset side, the procurement system (imported via Import Sets) is authoritative. The "right" value depends on the field — there is no single source of truth for the entire record.

Lifecycle State Alignment

Asset State	Typical CI State	Alignment Note
On Order	None (not yet in CMDB)	Asset exists; CI may not yet
In Stock (Receiving)	None / Draft	Physical item received, not deployed
In Use	Installed → Active	Should match; Discovery keeps CI current
In Maintenance	Maintenance	Should match; updated manually or via Change
Retired	Decommissioned	Both should be updated during offboarding

⚠

Exam Trap — Discovery Does NOT Update Asset Records ServiceNow Discovery updates CI records through IRE. It does not update Asset records. If a server is discovered and its OS version changes, the CI record updates but the Asset record is unaffected. Asset records are updated by procurement systems, service desk agents, or field technicians — not by Discovery.

Section 5

Creating Asset-CI Links

When a new CI is created by Discovery or a Service Graph Connector, the system checks whether a matching Asset record exists. The matching logic uses serial number, asset tag, or other identity attributes. There are three outcomes:

Match found — the CI and Asset are linked. Shared fields are synchronized per the sync rules.
No match found, auto-create enabled — a new Asset record is created and linked to the CI automatically.
No match found, auto-create disabled — CI is created with no Asset link. The Asset Management team must manually create and link the Asset record later. Common source of reconciliation gaps.

💡

Tip — Asset Tag vs. Serial Number for Matching The asset tag (a label physically attached to hardware) is a reliable matching key because it's manually applied and stable. The serial number is set by the manufacturer but sometimes gets overwritten by virtualization platforms. For servers in virtualized environments, use asset tag as the primary reconciliation key when matching Assets to CIs.

Exam Quick Reference

Common Exam Traps — Data Certification & Asset-CI Lifecycle

Data Certification marks records as verified — it does NOT update field values
Rejected certifications trigger tasks/changes to fix data; they don't auto-update the CI
Asset record = Finance/lifecycle view; CI record = IT/technical view — same physical object
Asset and CI linked via: alm_asset.ci → CI and cmdb_ci.asset → Asset
Discovery updates CI records only — never Asset records
Asset states (On Order → In Use → Retired) don't auto-sync to CI operational states
Lifecycle state mismatch between Asset and CI is a data quality issue detected by CMDB Health
Asset-CI reconciliation matching uses serial number or asset tag as identity keys
IRE is authoritative for CI technical fields; procurement system authoritative for Asset financial fields

Exam Checkpoint

Practice Questions

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

Data Certification & Asset-CI Lifecycle Quiz 1 / 4

A certifier reviews a CI in a Data Certification run and marks it "Rejected" because the support_group field is wrong. What happens to the CI record immediately after the rejection?

💡 Explanation

B is correct. Data Certification is a quality tracking process, not a data correction process. When a certifier marks a record "Rejected," the cert_result record is flagged and a task/change may be triggered to investigate and fix the CI — but the CI's actual field values are completely unaffected by the certification action. The CI data stays exactly as it was. This is a key exam trap: certification verifies data, it doesn't update it. The correction requires a separate workflow involving the responsible team updating the CI directly.