# Configuration Management Database (CMDB) Fundamentals
# Course Notes (structured from transcripts)

Source: /Users/weishen/mnt/volume2/knowledgebase/course/Pluralsight.Configuration.Management.Database.CMDB.Fundamentals.2026.BOOKWARE-GETH
Generated: 2026-09-19
Note: 22 video transcripts across 3 chapters. Instructor: Ramiz. Pluralsight 2026.

---

## Chapter 1 — 01. Course introduction

**Core Insights**
- CMDB solves the problem of configuration data scattered across spreadsheets, ticketing systems, and outdated documentation.
- The CMDB is positioned as the backbone of modern IT operations: faster incident management, safer change management, and real IT visibility.
- A neglected CMDB turns change management into guesswork and makes impact analysis impossible.
- The course is structured in three modules: foundation (Module 1), hands-on building (Module 2), and ongoing quality/governance (Module 3).
- Target outcome: ability to understand, build, and maintain a CMDB that genuinely supports IT operations.

**Detailed Notes**
*Course Motivation*
- IT teams lack a clear picture of what is running and how everything connects when incidents occur or changes go wrong.
- ServiceNow CMDB is presented not as a nice-to-have but as a foundation for incident, change, and visibility.

*Course Roadmap*
- Module 1 — What the CMDB is, why it matters to ITSM, and the real benefits of maintaining it well.
- Module 2 — Hands-on: creating CIs, defining relationships, populating the CMDB with different methods, building a working configuration database.
- Module 3 — Ongoing work: monitoring CMDB quality, fixing common data issues, implementing governance for long-term reliability.

**Action Items**
- List where configuration data currently lives in your organization (spreadsheets, ticketing, docs) to scope the CMDB problem.
- Map the three-module structure onto your learning plan before starting hands-on lab work.

**Key Terms/Concepts**
- **CMDB (Configuration Management Database)**: central repository of IT configuration data; the single source of truth for what is running and how components connect.

## Chapter 1 — 02. What is the CMDB in ServiceNow

**Core Insights**
- The CMDB is a centralized repository — a master inventory of configuration items (CIs) such as servers, databases, applications, network switches, and printers.
- In ServiceNow everything lives in the base table `cmdb_ci`; specialized tables (server, database, application) inherit from it.
- The CMDB's power is in relationships: it maps how components connect, turning raw data into intelligence (e.g., server ABC hosts app XYZ, connects to DB 123).
- The CMDB is dynamic — it should reflect real-time infra changes, showing what is actually running, not what should be running.
- CIs carry essential attributes (name, manufacturer, vendor, location, operational status) that tell the story of each asset.

**Detailed Notes**
*What Counts as a CI*
- Any part of IT infrastructure with relationships to other components qualifies — servers, databases, switches, applications, software, even printers.

*Table Architecture*
- `cmdb_ci` is the core base table where all CIs live; child tables like `cmdb_ci_server`, `cmdb_ci_database`, `cmdb_ci_application` branch from it.

*Three Pillars of Value*
- Centralized: one place instead of per-team spreadsheets — answering questions doesn't require pinging five people.
- Relationship-aware: spreadsheet says a server exists; CMDB says what it hosts, connects to, which licenses it needs, its team, and which services break if it goes down.
- Dynamic: reflects constant provisioning, retirement, and configuration shifts.

*Cost of Neglect*
- Outdated CIs and missing relationships make change management a guessing game, lengthen incident resolution, and break root-cause analysis — inefficient and dangerous.

**Action Items**
- Inventory your key CI types and verify they could be modeled under the `cmdb_ci` hierarchy in ServiceNow.
- For one critical server, write out its full relationship map as a warm-up exercise for CMDB modeling.

**Key Terms/Concepts**
- **Configuration Item (CI)**: any component of IT infrastructure worth tracking in the CMDB.
- **Base table (cmdb_ci)**: root table from which all CI classes inherit.
- **Relationship**: documented connection between CIs that enables impact analysis.
- **Single source of truth**: one authoritative, accurate record of infrastructure configuration.

## Chapter 1 — 03. Demo Understanding the CMDB interface

**Core Insights**
- The CMDB application in ServiceNow is organized into modules for management, health, and data exploration.
- Management modules: CMDB 360 query schedules, Class Manager (class hierarchy, identification and reconciliation rules), Groups, Query Builder, Health Preferences, Remediation, Reports, and Exclusion List.
- Health visibility: the CMDB Health Dashboard measures completeness, correctness, and compliance.
- Category modules (application server, servers, clusters, database, network) list specific CI types; clicking a record opens the full CI with attributes.
- The Exclusion List prevents specific items from being created/updated as CIs — commonly paired with Discovery.

**Detailed Notes**
*Management Modules*
- CMDB 360 query schedules: scheduled queries for a 360-degree view of a CI across the CMDB.
- Class Manager: centralized management of class hierarchy, identification rules, and reconciliation rules.
- CMDB Groups: logical grouping of CIs for management, reporting, and access control.
- Query Builder: build complex queries spanning multiple CI classes and relationships without code.
- Health Preferences: settings driving how CMDB health is measured.
- CMDB Remediation: track/manage actions fixing data quality issues.
- Reports: pre-built reports for visibility into CMDB data.

*Health and Data Modules*
- Health Dashboard shows visual metrics of completeness, correctness, and compliance.
- Category modules such as application server, servers, clusters, database servers, database instances, and network group related CI types; e.g., network groups different network device types.
- Opening a category (e.g., database) shows the CI list; clicking through opens the CI record with all attributes.

**Action Items**
- In a personal developer instance, navigate to Configuration and click through each module once to build spatial memory of the interface.
- Open the Class Manager and review the identification/reconciliation rule options available by default.

**Key Terms/Concepts**
- **Identification rule**: logic that decides whether a discovered item matches an existing CI or creates a new one.
- **Reconciliation rule**: logic resolving attribute conflicts between data sources.
- **Exclusion List**: items blocked from being created/updated as CIs.
- **CMDB Health**: measurement of data completeness, correctness, and compliance.

## Chapter 1 — 04. CMDB and ITSM process integration

**Core Insights**
- The CMDB is the thread tying incident, problem, change, and asset management together.
- Incident management: linking an incident to a CI instantly reveals dependencies, downstream systems, and impacted users — cutting investigation time from ~30 minutes to seconds.
- Problem management: relationship data turns five seemingly unrelated incidents into an obvious pattern pointing to a common root cause.
- Change management: impact analysis shows the blast radius (dependent apps, downstream risk) before approval — without it, change management is guesswork.
- Configuration data flows both directions: executed changes update the CMDB (patches recorded, retired apps marked inactive, new databases added).

**Detailed Notes**
*Incident Management*
- First step on an incident (e.g., slow accounting app) is linking it to the relevant CI — the app itself or its hosting server.
- From the CI, teams see what depends on it, what databases feed it, and what systems are downstream.

*Problem Management*
- Five incidents sharing a cause (e.g., a failed network switch) become visible as one pattern via relationship data, enabling root-cause analysis and preventing cascading failures.

*Change Management*
- Before approving a change (e.g., patching a DB server), the dependency map shows affected applications and the full impact chain.
- Data-driven scheduling, testing, and stakeholder notification replace guesswork.

*Bidirectional Flow*
- Changes feed back into the CMDB: patches, retirements, and provisioning keep records current.

**Action Items**
- For each incident template in your org, define which CI linkage should be mandatory.
- Draft an impact-analysis checklist for change requests that queries the dependency map before approval.

**Key Terms/Concepts**
- **Affected CI**: configuration items directly impacted by an incident.
- **Blast radius**: the set of downstream components at risk when a change is applied.
- **Impact analysis**: evaluating consequences of a change using CMDB relationships.

## Chapter 1 — 05. Demo Incident linked to CMDB

**Core Insights**
- Incidents carry two distinct tabs: Affected CIs (directly impacted, being worked on) and Impacted Services/CIs (downstream business services affected via relationships).
- Affected CI lists speed resolution — technicians know exactly which systems are involved with no guessing or email chasing.
- Repeated appearance of the same CI across incidents is a strong signal for problem management root-cause analysis.
- Impacted services give a service-centric view that drives prioritization, SLA tracking, customer communication, and major incident decisions.
- Clicking a CI (e.g., SAP App SRV01) opens the full CI record with attributes and a related-items dependency list — the link between incidents and the rest of ITSM.

**Detailed Notes**
*Demo Walkthrough*
- Navigate to Incident → Open, select an incident, and review standard fields: short description, caller, priority, assignment group, state.
- The Affected CI tab lists CIs directly involved in the incident; the Impacted Services/CIs tab shows downstream business services derived from CMDB relationships.

*Value to Roles*
- Incident resolution: immediate identification of the affected server, application, or database.
- Problem management: pattern detection when the same CI recurs across incidents.
- Management: a service-centric view — seeing degraded business services, not just a broken server.

*CI Record Drill-Down*
- Clicking SAP App SRV01 opens a server CI showing name, class, operational status, owner, location, and related items with all dependencies.

**Action Items**
- Standardize the practice of always linking incidents to affected CIs in your instance.
- Build a recurring report of top CIs by incident count to surface potential problems early.

**Key Terms/Concepts**
- **Affected CIs tab**: CIs directly impacted and under investigation for the incident.
- **Impacted Services/CIs tab**: downstream services and CIs affected as a consequence, derived from CMDB relationships.

## Chapter 1 — 06. Benefits of a well-maintained CMDB

**Core Insights**
- Operational benefits: faster incident resolution, outage prevention via single-point-of-failure discovery, and higher change success rates.
- Strategic benefits: infrastructure-wide visibility enables cost savings (retiring redundant apps, capacity optimization), true service dependency mapping, and data-driven strategic decisions (cloud migration, consolidation).
- Governance benefits: compliance audits, risk identification (unsupported OS, end-of-life apps), and organizational accountability through CI ownership.
- Prevention is cheaper than firefighting — reinforcing critical paths before they break.
- The real value isn't what you spend on the CMDB; it's what you save: time, money, effort, and risk.

**Detailed Notes**
*Operational Benefits*
- Incident resolution: teams instantly see context, dependencies, and impact from the affected CI.
- Outrage prevention: accurate relationships reveal hidden vulnerabilities and single points of failure.
- Change success: better planning, testing, and communication raise change success rates and cut production incidents.

*Strategic Benefits*
- Visibility/optimization: answer which servers are underutilized, which apps are redundant, where investment is over-concentrated.
- Service dependency mapping: surface hidden chains (e-commerce → server C → SAN → network segment; financial system outage blocks payments).
- Strategic decision making: answer cloud migration, app migration, and data-center consolidation questions with data.

*Governance Benefits*
- Compliance: audit trail proving what runs in the environment for regulated industries (healthcare, finance, government).
- Risk management: flag unsupported OS, end-of-life applications, compliance gaps, lifecycle risks.
- Accountability: CI owners, tracked changes, documented relationships make people take better care of owned infrastructure.

**Action Items**
- Run a report to identify single points of failure in your critical service paths.
- Create a compliance query flagging CIs on unsupported OS versions or past end of life.

**Key Terms/Concepts**
- **Single point of failure**: a CI whose outage breaks critical services and has no redundancy.
- **Service dependency mapping**: documented chain of how business services are constructed from underlying CIs.
- **Configuration baseline**: snapshot of configuration at a point in time used for change impact and compliance.

## Chapter 1 — 07. CMDB terminology and ITIL evolution

**Core Insights**
- Configuration management is a discipline, not just a database: identifying, tracking, and maintaining CI information involving people, tools, and governance.
- Attributes (name, vendor, serial, location, status) make a CI valuable; relationships (runs-on, connects-to) are typed and drive impact analysis.
- CI classes form an inheritance hierarchy rooted at the base CMDB CI table; server CIs inherit base attributes plus server-specific ones (CPU, RAM, OS).
- The CMDB originates from ITIL, which defined configuration management in the 1980s; ServiceNow's CMDB is built on ITIL principles.
- ITIL process parts: planning, identification, control, verification/audit — with supporting concepts like configuration baseline and release management.

**Detailed Notes**
*Core Terminology*
- Configuration items: the entities themselves.
- Configuration management: the whole process discipline of identifying, tracking, and maintaining CI info.
- Attributes: fields in a CI record; value comes from completeness and accuracy.
- Relationships: typed connections (e.g., app runs-on server, server connects-to switch) that matter for impact analysis.
- CI class structure: hierarchy with base `cmdb_ci` table and subclasses (server, database, application) inheriting attributes.

*ITIL Evolution*
- ITIL (Information Technology Infrastructure Library) is the world's widely adopted ITSM framework; it defined the CMDB concept in the 1980s.
- Process steps: planning (what to track and why), identification (register CIs with attributes/relationships), control (keep CMDB updated as infra changes), verification and audit (regularly confirm CMDB matches reality).
- Configuration baseline: a point-in-time snapshot (e.g., production as of March 1st) for change impact and compliance.
- Release management: deploying a new app version is a release; the CMDB records it and captures dependency shifts.

**Action Items**
- Define your tracking strategy first: decide which CI classes matter before populating anything.
- Set up a recurring verification/audit cadence so the CMDB is checked against reality.

**Key Terms/Concepts**
- **ITIL**: Information Technology Infrastructure Library, the widely adopted ITSM framework.
- **Configuration baseline**: snapshot of configuration at a specific point in time.
- **Identification**: registering CIs with attributes and relationships.
- **Control**: ensuring the CMDB is updated when infrastructure changes.
- **Verification and audit**: periodically confirming CMDB accuracy against reality.

## Chapter 1 — 08. Demo CMDB in action

**Core Insights**
- `cmdb_ci.list` is a quick navigator shortcut to the CMDB table; the demo instance holds 2,786 CIs (real orgs often have tens to hundreds of thousands).
- Grouping CIs by class reveals how ServiceNow organizes infrastructure logically (AIX servers, applications, clusters, databases, email servers, IP routers, etc.).
- A CI record has identification fields (name, asset tag, manufacturer, serial, model), configuration details (device type, IP, location, port), and a related-items section listing typed relationships (depends on/used by, member of).
- The Dependency View renders the whole topology as an interactive map with layouts (vertical, horizontal, radial, force, groups) and filters (dependency depth, CI type, manufacturer).
- The ITSM bridge: an incident's impacted service (SAP Enterprise Service) opens a dependency map showing five related incidents and a linked problem record — a strong root-cause signal connecting CMDB to incident and problem management.

**Detailed Notes**
*CMDB Table Walkthrough*
- Navigate via `cmdb_ci.list`; columns include name, manufacturer, location, description, class, updated, maintenance schedule.
- Grouping by class shows the logical organization of infrastructure in the instance.
- Drilling into an IP router CI: identification fields at top; configuration details (device type, IP address, location, port, channel, firmware manufacturer) below; related items at bottom with depends-on/used-by and member-of relationships.

*Dependency View*
- Visualizes topology as a map instead of relationship lines; layout options adapt the view to the analysis goal.

*ITSM Integration*
- Opening an incident shows affected CIs and impacted services; the impacted service is SAP Enterprise Service.
- From the incident's dependency map, details reveal five incidents reported against the CI — the incident manager sees isolated vs. systemic issues; the problem manager sees a root-cause signal.
- A linked problem record shows the team already investigating the recurring issue; filters narrow the view by dependency level, CI type, or manufacturer.
- Real-world pattern: see the CI, see dependencies, link to incidents and problems, drive faster resolutions — used in banking, telecom, healthcare, manufacturing.

**Action Items**
- Practice navigating with `<table_name>.list` shortcuts to reach CMDB records quickly.
- Use the dependency view's filters to build reusable views per service for impact analysis.
- Configure a monitoring pattern: repeated incidents on one CI should auto-flag for problem management.

**Key Terms/Concepts**
- **Dependency View**: interactive topology map of a CI's relationships with multiple layouts and filters.
- **`.list` shortcut**: navigator syntax (`table_name.list`) jumping straight to a table's list view.
- **Impacted service**: business service degraded as a downstream consequence of an incident.

---

## Chapter 2 — 01. CMDB data model and CI class structure

**Core Insights**
- The CI class hierarchy is the blueprint of the CMDB: every configuration item inherits from a single base table, `cmdb_ci`.
- Inheritance makes the data model scalable — base attributes (name, short description, operational status, discovery source) apply to all CIs, while specialized child classes add type-specific attributes (CPU/RAM for servers, database-specific fields for databases).
- There is no single "correct" CI scope; organizations must decide which CI types to track based on needs and governance strategy.
- ServiceNow allows extending the hierarchy with custom CI classes, but flexibility demands governance or the CMDB becomes messy and inconsistent.
- Design CI classes with consistency, completeness, and scalability in mind; getting the structure right first prevents months of data cleanup later.

**Detailed Notes**
*The Inheritance Model*
- `cmdb_ci` is the parent/base table; every CI record traces back to it. First-level specializations include database, server, application, and computer categories.
- Child tables inherit all parent fields and add their own specialized attributes — same structure, different detail per class.
- Example path in ServiceNow: Server → Computer → cmdb_ci.

*CI Planning (part of ITIL configuration management)*
- Before creating CIs, define: which infrastructure types to track, which attributes matter per type, and who owns maintenance of each type.
- Scope decisions vary: some orgs track every device (printers, switches, UPS), others stay business-centric (servers, databases, applications).

*Governance Principles*
- Consistency: a server CI should look like every other server — same attributes, naming, relationships.
- Completeness: capture what you need to know (e.g., tracking servers without OS is a critical gap).
- Scalability: the structure must accommodate new infrastructure types without breaking.

**Action Items**
- Document a CI class plan before building: list tracked types, mandatory attributes, and data owners.
- Enforce naming conventions and standard attributes per CI class across all creating teams.
- Review the out-of-box class hierarchy and only create custom classes where a genuine gap exists.

**Key Terms/Concepts**
- **CI class structure**: The inheritance hierarchy of tables defining what attributes and behavior each configuration item type has.
- **cmdb_ci (Configuration Item base table)**: The root table all CI records inherit from, holding universal attributes.
- **Inheritance**: Child tables automatically receive all parent fields and add type-specific fields.
- **CI planning**: The ITIL-aligned activity of deciding what infrastructure to track and how.

## Chapter 2 — 02. Demo Exploring CI class structure in ServiceNow

**Core Insights**
- The CMDB is not one table — it is an ecosystem of thousands of tables, each storing a specific type of configuration data.
- All CI tables inherit from the single root base table `cmdb_ci`; this was demonstrated live on a ServiceNow personal developer instance.
- Grouping tables by their "extends table" column reveals the parent–child hierarchy behind the scenes.
- Structural changes made at the base table level propagate automatically to every CI class in the CMDB.

**Detailed Notes**
*Navigating the Table Landscape*
- Filter Navigator → Tables; the demo instance contained 6,207 total tables, each like a spreadsheet with defined columns and rules (incidents, users, changes, CMDB each live in separate tables).
- Filtering labels by "CMDB" surfaced 5,000+ CMDB-related tables — evidence the CMDB is a family of tables.
- Filtering names by `cmdb_ci` narrowed to 596 tables, all specialized children of the same base CI table: servers, databases, applications, and more.

*Viewing the Hierarchy*
- Grouping by the extends table column produced 73 parent–child groups.
- Expanding "Configuration Item" showed only one table extends directly from it: `cmdb_ci` itself — the root of the entire hierarchy.
- Every server, database, and application table ultimately traces back to this one base table.

**Action Items**
- In your own instance, use the Tables list filtered by `cmdb_ci` to inventory existing CI classes before creating new ones.
- Use the "group by extends table" view to map your CMDB hierarchy and spot duplicate or orphaned classes.
- Audit base-table field changes carefully since they cascade to every child class.

**Key Terms/Concepts**
- **Staging/extends relation**: A table's parent in the inheritance hierarchy, shown as the extends table column.
- **PDI (Personal Developer Instance)**: A free personal ServiceNow instance used for learning/demos.
- **Table**: The storage structure in ServiceNow; all data lives in tables.

## Chapter 2 — 03. Creating and managing CIs

**Core Insights**
- Two creation paths exist: manual form entry and automated discovery; imports via import sets/transform maps handle bulk population.
- Manual creation is precise but does not scale — for hundreds of CIs it is unrealistic, error-prone, and stale the moment it is done.
- Discovery tools scan infrastructure and populate the CMDB automatically, but still require governance around approvals, validation, and ownership.
- Import sets stage raw data into a temporary table; transform maps define column-by-column mappings into the target CMDB table.
- Quality over perfection: an 80%-complete, actively used CMDB beats a perfect one that was never started.

**Detailed Notes**
*Manual Creation*
- Fill a form: basics (name, description, type), then type-specific details (OS, CPU, RAM, manufacturer, owner, location, support group).
- Which attributes are mandatory vs. optional must be defined in governance policy (e.g., name + OS + owner minimum).

*Automated Discovery*
- Agents/scanners find components: Windows discovery agents for servers, SNMP for network devices, dedicated processes for databases and applications.
- Discovery can auto-create CIs and relationships — but who approves and validates new CIs are governance questions.

*Import Sets & Transform Maps*
- Import set = staging table where raw data lands; transform map = rule mapping source columns to target fields (e.g., spreadsheet server name column → CI name field).
- Powerful for initial population from a source of truth (inventory system, spreadsheet); quality is still garbage-in, garbage-out.

*CI Attributes & Best Practices*
- Core attributes: name (unique, follow naming conventions), type (class), owner (accountability), status (lifecycle: in use/in development/retired), location (physical/cloud region).
- Operational attributes: CPU, RAM, OS, version, component-specific configuration.
- Populate attributes that drive incident/change decision-making rather than collecting everything.

**Action Items**
- Define mandatory vs. recommended attributes per CI type in a written governance policy.
- Start small: load critical servers and key applications, define relationships, and use the CMDB in incident/change workflows.
- Establish an iteration loop to identify and close data gaps as the CMDB is used.

**Key Terms/Concepts**
- **Import set**: A staging table holding raw imported data before transformation into the CMDB.
- **Transform map**: Defines how source columns map to target CMDB fields during import.
- **Discovery**: Automated agents that scan infrastructure and populate CI data.
- **Lifecycle status**: A CI's state (in use, in development, retired) tracked for governance.

## Chapter 2 — 04. Demo Creating a CI

**Core Insights**
- A CI is created from a blank, class-specific form — the demo created a server CI manually on a PDI.
- Key identification fields: name (unique identifier), company, asset tag, and serial number.
- The assignee/owner field is among the most important — no owner means no accountability for keeping the CI accurate.
- Server-specific fields (OS, RAM) only exist on the server table, demonstrating inheritance in action.
- The manual workflow is identical across all CI types: fill identification, set owner, add type-specific attributes, save, verify.

**Detailed Notes**
*Demo Walkthrough*
- Filter Navigator → "configuration" → Servers → All (41 existing server CIs) → New to open a blank server form.
- Filled: name `serve prod 01`, company Acme (business unit owner), asset tag SV41, serial number 123456789.
- Assigned to a user (Antony) — the owner accountable for record accuracy.
- Server-only attributes: OS (Hyper-V) and RAM; real implementations would add CPU count, disk space, IP address.
- Submitted, then verified the CI appeared in the server list.

*Verification*
- Added the "Updated" column via the gear icon to spot the newest record; sorting by that column put `serve prod 01` at the top.
- The record is stored in the cmdb_ci_server table.

**Action Items**
- Standardize which identification fields are mandatory for each CI class before enabling creation.
- Always assign an owner/assignee on every CI record.
- Use the Updated column sort to routinely spot stale CMDB records.

**Key Terms/Concepts**
- **Asset tag**: An organization's internal asset tracking number for the CI.
- **Serial number**: The manufacturer's unique hardware identifier.
- **Assignee**: The person accountable for the CI's data accuracy.

## Chapter 2 — 05. Defining and visualizing CI relationships

**Core Insights**
- A CI in isolation is just a record; relationships give the CMDB its power, connecting CIs so the data becomes intelligent.
- Relationship types carry meaning: Runs on, Connects to, Part of, Depends on, Backed up by, Managed by — each affects impact analysis differently.
- Relationships can come from discovery (auto-created), manual definition, bulk import via transform maps, or be added organically during incident/change work.
- Visualizing relationships (dependency maps) enables instant impact analysis: if a database goes down, which applications break?
- Start with high-value, critical relationships for your most important services and expand iteratively — don't map everything on day one.

**Detailed Notes**
*Common Relationship Types*
- Runs on: application/service runs on one or more servers.
- Connects to: server connects to a database; application talks to an API.
- Part of / Grouped in: server part of a cluster; database part of an instance group.
- Depends on: a service depends on a supporting application/shared library.
- Backed up by: a system protected by a backup solution.
- Managed by: an infrastructure component managed by a systems team.

*Defining Relationships at Scale*
- Small environments: click-through manual definition is feasible.
- Large environments: discovery finds installed applications and auto-defines run-on relationships; spreadsheets/CMDB tools can be imported in bulk; users add relationships as they discover them.

*Visualization & Impact Analysis*
- Dependency maps show the full chain: applications → servers → databases → backup systems.
- Answering "what breaks if X fails?" becomes a glance at the map — operational intelligence for change decisions and incident response.

**Action Items**
- Identify and model the critical dependency chains for your top business services first.
- Test impact analysis on the mapped relationships before expanding coverage.
- Prefer discovery-generated relationships for installed-software dependencies; reserve manual effort for what discovery cannot model.

**Key Terms/Concepts**
- **Impact analysis**: Determining downstream effects when a CI fails or changes.
- **Dependency map**: A visual graph of CIs and their directional relationships.
- **Relationship type**: A labeled, directional connection (runs on, depends on, etc.) between CIs.

## Chapter 2 — 06. Demo Creating and visualizing relationships

**Core Insights**
- The related-items section on any CI record lists all relationships, each with direction and meaning (depends on, used by, exchanges data with).
- L1/L2/L3 labels indicate dependency depth: L1 is directly connected, L2 one hop away, L3 two hops away — the foundation of impact analysis.
- A freshly created CI sits in isolation; relationships are what bring the CMDB to life.
- The relationship editor lets you pick relationship types and connect a CI to other CIs; results appear immediately in the dependency map.

**Detailed Notes**
*Demo Walkthrough*
- Opened the master view (`cmdb_ci.list`), grouped by class, and opened an AIX server record (SAP App SRO 2).
- Related items showed: web servers "Depend on / used by" the server; storage/database as parents the server depends on; "Exchanges data with" both child Windows servers and parent mass-storage devices.
- Explained L1 (direct neighbors, hit immediately on failure), L2 (one hop), L3 (two hops) — at risk depending on the chain.
- Opened the dependency map showing the server centered with arrows to its dependencies and dependents.

*Creating Relationships*
- Plus icon opens the relationship editor: suggested types across the top (connects to, depends on, used by, child/parent), filters, and a CI picker below.
- Selected "depends on / used by" and added three CIs (Thinkpad T20, MacBook Pro 15, DP00315), then "receive data from" and "connects to / child" with more CIs; saved.
- The dependency map and related-items list both updated to show all new relationships.

**Action Items**
- Review the related-items section and dependency map on your most critical CIs as a first impact-analysis exercise.
- Use L1/L2/L3 depth to prioritize which connections to keep accurate first.
- Use the relationship editor's type suggestions rather than free-typing to keep relationship vocabulary consistent.

**Key Terms/Concepts**
- **Related items**: The section of a CI record listing all its relationships.
- **L1/L2/L3 dependency depth**: Distance of a connected CI from the CI of interest (direct, one hop, two hops).
- **Relationship editor**: UI for adding and typing relationships between CIs.

## Chapter 2 — 07. Methods of populating the CMDB

**Core Insights**
- Four approaches exist: manual creation, automated discovery, import sets/transform maps, and the hybrid approach — which most mature organizations actually use.
- Manual gives complete control but is time-intensive, error-prone, non-scalable. Discovery automates at scale and builds relationships, but only covers discoverable infrastructure and needs configuration.
- Import sets bulk-load fast from external sources but depend on source-data quality and require transform-rule definition.
- Data quality is decisive: garbage in, garbage out. Validate sources, map to standards, assign ownership, and enforce mandatory attributes.
- A realistic phased rollout: discovery first, manual for gaps, import the application portfolio, define relationships, then iterate with real usage.

**Detailed Notes**
*Method Comparison*
- Manual: use for specialized items that don't fit discovery patterns, small initial setups, or CI types needing specific manual entry.
- Discovery: Windows agents, SNMP scanners for network devices, database discovery — finds what is actually running and auto-creates relationships; data quality depends on the process.
- Import sets/transform maps: export from spreadsheet, competing CMDB, or inventory tool → stage → transform → bulk load; ideal for initial population and legacy migration.
- Hybrid: discovery for servers/network, manual for specialized components, import sets for application data from an APM/portfolio tool.

*Data Quality Best Practices*
- Validate source data before import or discovery.
- Enforce naming conventions, standard attributes, and consistent status values (no "server 123" vs "production server UK01").
- Assign ownership so someone is accountable for stale records.
- Define mandatory attributes per CI type; don't leave every field optional.

*Realistic Scenario (mid-sized org)*
- Phase 1: discovery finds ~150 Windows servers and network devices.
- Phase 2: manually add ~50 servers without agents (Unix, legacy, out-of-band devices).
- Phase 3: bulk import 300+ applications from the APM/portfolio tool.
- Phase 4: define server–application relationships (part automated, part manual).
- Phase 5: iterate — use the CMDB, find gaps, fix them.

**Action Items**
- Choose a population method per CI category rather than one method for everything.
- Write naming and status-value standards before the first import or discovery run.
- Build a phased rollout plan with explicit governance checkpoints (approval, validation, ownership).

**Key Terms/Concepts**
- **SNMP scanner**: Discovery mechanism for network devices.
- **APM (Application Portfolio Management)**: A tool holding application inventory, often a source for imports.
- **Hybrid approach**: Combining manual, discovery, and import methods based on situation.

## Chapter 2 — 08. Demo Import sets and discovery

**Core Insights**
- The import flow is: create a staging table → load raw data → build a transform map → run the transform → verify CIs landed in the target table.
- Import sets can be new per import or reused for recurring imports of the same structure; sources can be files (CSV/Excel) or configured data sources (FTP, JDBC, REST).
- A transform map is the bridge that tells ServiceNow which source column goes to which target field — without it, the staged data has no destination.
- Auto-mapping works only for exactly matching column names; mapping assist gives a controlled visual editor for manual mapping.
- Completion code "success", a complete import-set run state, and target-record links verify the transform cleanly.

**Detailed Notes**
*Demo Walkthrough*
- Prepared a sample CSV of 10 laptop records (name, asset tag, manufacturer, serial, OS, location, department, owner, CPU count, RAM, hard disk, IP, MAC, operational status).
- System Import Sets → Load Data → created a new staging table (label: computer import CMDB test), uploaded the CSV.
- The import-set state showed "loaded" — data staged but not yet in the CMDB; all 10 rows visible under the import set rows tab.
- Created a transform map: source = staging table, target = cmdb_ci_computer; used mapping assist to map nine fields (asset tag, CPU count, department, IP, MAC, manufacturer, etc.).
- Ran the transform: completion code success; all 10 records got target-record links; the import-set run state was "complete".

*Verification*
- Opened `cmdb_ci_computer.list` and confirmed all 10 CIs present.
- Added asset tag, CPU count, MAC, IP, model, and RAM columns to verify imported values match the spreadsheet exactly.

**Action Items**
- Reuse an existing staging table for recurring imports of identical structure to keep the process streamlined.
- Prefer mapping assist when source column names deviate from target field names.
- Always verify imported CIs by checking target-record links and spot-checking a few attribute values.

**Key Terms/Concepts**
- **Staging table**: Temporary holding area for raw import data before transformation.
- **Transform map**: Defines source-to-target field mappings between staging and CMDB tables.
- **Mapping assist**: Visual editor for manually mapping source fields to target fields.
- **Import set run**: A record of a completed transformation run with its state.

---

## Chapter 3 — 1. CMDB data quality and integrity

**Core Insights**
- Building a CMDB is easy; keeping it reliable over time is the hard part — a CMDB decays like an untended garden unless continuously maintained.
- Data quality and integrity are the foundation of trust: impact analysis, incident response, and change approvals are only as good as the CMDB data behind them.
- Data quality has four dimensions: completeness, accuracy, consistency, and currency.
- Maintaining quality is an organizational problem, not a technical one — ownership, governance, audits, process integration, and education.
- Without attention the CMDB drifts into entropy: records go stale, relationships age, and nobody notices until a bad decision is made.

**Detailed Notes**
*What Defines a Healthy CMDB*
- A healthy CMDB is one where you can trust the data for decisions — approving changes via impact analysis, incident responders tracing relationships.

*The Four Dimensions of Data Quality*
- **Completeness**: essential attributes populated (e.g., every server has an owner); not every field, just what decisions require.
- **Accuracy**: data matches reality (e.g., actual OS version vs. recorded version) — small errors compound in compliance and support-lifecycle decisions.
- **Consistency**: standardized naming and formatting ("Prod App Server 1" vs. "Production App Server 2" breaks search and reporting).
- **Currency**: records reflect the current state, not a historical record — decommissioned servers and upgraded apps must be updated.

*Operational Consequences of Bad Data*
- Incident management may miss affected systems and resolve without addressing root cause.
- Change management may approve risky changes when the CMDB understates what a CI supports.
- Configuration management cannot enforce standards against an untrusted source of truth.

*How to Maintain Data Quality*
- Every CI needs a named owner or it will decay; define and enforce standards (attributes, naming, statuses); schedule audits comparing the CMDB to reality; integrate CMDB updates into provisioning/decommissioning/deployment processes; educate users with real examples of bad decisions caused by bad data.

**Action Items**
- Assign an owner to every CI and make the list of ownerless records a tracked metric.
- Define mandatory attributes per CI type, a naming convention, and valid status values; write them down and publish them.
- Schedule recurring audits (compare CMDB entries against live infrastructure) and hold teams accountable for discrepancies.
- Wire CMDB updates into standard operating processes so they happen automatically, not as an afterthought.
- Run a training session showing real cases where stale or missing CMDB data caused a costly or risky decision.

**Key Terms/Concepts**
- **Completeness**: degree to which essential, decision-driving attributes are populated on CI records.
- **Accuracy**: how closely recorded CI data matches the real-world component.
- **Consistency**: uniformity of naming, formatting, and status values across records.
- **Currency**: how current records are relative to the actual infrastructure state.
- **Entropy (CMDB decay)**: the natural drift of CMDB data toward staleness and error when no one actively maintains it.

## Chapter 3 — 2. Using CMDB health dashboards

**Core Insights**
- Health dashboards turn vague "is our CMDB good?" into quantifiable scores that show where problems live.
- Trending over time is the real power: visibility into improvement or decay tells you whether governance efforts are working.
- The ServiceNow dashboard computes KPIs from your governance rules — completeness, accuracy, and compliance are only meaningful relative to standards you define.
- Measure what matters to your organization: align metrics with incident management, change, or other priorities instead of tracking everything.
- Metrics drive behavior — tracking something makes people improve it, and declining scores force accountability.

**Detailed Notes**
*Dashboard KPIs*
- **Completeness score**: percentage of CIs with mandatory attributes populated, calculated from governance rules; 95% is good, 60% signals work to do.
- **Accuracy metrics**: automatically detectable issues like CIs with no relationships or orphaned records.
- **Compliance**: CIs meeting governance standards, e.g., production servers must link a backup solution.

*The Power of Trending*
- Scores tracked over months show improvement or degradation; a dropping score means governance is not preventing decay; an initiative that lifts the curve proves measurement drives results.

*Customizing What You Measure*
- Tailor metrics to priorities: % of CIs with SLA info, missing relationships, % of applications with documented dependencies, data freshness vs. reality.
- If incident management is the priority, measure data incident managers rely on; if change is critical, measure the data change managers need.

*Key Metrics Worth Tracking*
- **Discovery coverage**: % discovered automatically vs. manually created — more discovery catches new infrastructure automatically.
- **Relationship density**: average relationships per CI — near-zero suggests missing definitions, dozens suggests over-granularity.
- **Freshness/verification age**: when each CI was last verified; unverified for 6+ months is stale.
- **Ownership coverage**: % of CIs with assigned owners — ownerless CIs decay.
- Showing completeness climbing from 65% to 78% demonstrates progress and creates accountability.

*Practical Approach*
- Don't fix everything at once: pick the high-value CI type first (e.g., servers, databases), drive it past 90% completeness, then iterate.

**Action Items**
- Configure the health dashboard and note the baseline overall score and per-KPI values before any cleanup.
- Define mandatory and recommended attributes per CI type so completeness scores are meaningful.
- Set up a monthly trend review of the three KPIs; investigate any month-over-month decline immediately.
- Choose 3-5 custom metrics aligned to your biggest operational pain (incident, change, or compliance) and track only those first.
- Prioritize one high-value CI class (e.g., servers) and target 90%+ completeness before expanding scope.

**Key Terms/Concepts**
- **CMDB Health Dashboard**: ServiceNow tool showing overall CMDB health scores and surfacing where problems are.
- **Completeness Score**: % of CIs meeting mandatory-attribute governance rules.
- **Compliance KPI**: % of CIs satisfying governance audit rules (e.g., backup linked, owner assigned).
- **Discovery coverage**: share of infrastructure captured automatically by discovery vs. entered manually.
- **Relationship density**: average number of relationships per CI, used to spot missing or over-granular relationship definitions.
- **Freshness**: how recently each CI was verified accurate, tracked via timestamps.

## Chapter 3 — 3. Common CMDB data issues and remediation

**Core Insights**
- The five classic CMDB problems are duplicates, orphans, wrong relationships, missing attributes, and stale data — each with a distinct remediation path.
- Prevention beats remediation: enforce naming standards, run duplicate detection regularly, and validate data at entry.
- Prioritize fixes by impact × effort: high-impact/low-effort quick wins first; skip low-impact/high-effort items.
- Many fixes (relationships, attributes, freshness) require subject-matter-expert validation — remediation is a people process, not just a technical one.
- Remediation is never a one-time project; a five-phase loop of identify → triage → fix → measure → govern keeps issues from undermining trust.

**Detailed Notes**
*Issue 1: Duplicate CIs*
- Same physical component recorded multiple times (e.g., "ProdDB01" vs. "proddb01"); duplicates confuse relationships, skew metrics, and link incidents to the wrong CI.
- Remediation: merge using ServiceNow's merge tool — pick the master record, merge the rest, relationships update automatically.
- Prevention: strict naming conventions plus regular duplicate detection.

*Issue 2: Orphan CIs*
- CIs with no relationships — unused apps, disconnected servers, isolated databases; either the CI is obsolete and not retired, or relationships are missing.
- Remediation: investigate; then delete it, mark it retired, or add the missing relationships.

*Issue 3: Wrong/Outdated Relationships*
- E.g., Server A no longer uses database B; an app was migrated away a month ago.
- Remediation: harder — requires system owners to validate whether the relationship still exists before deleting/updating.

*Issue 4: Missing Attributes*
- No OS specified, no version, no owner.
- Remediation depends on the attribute: query external systems where possible, otherwise survey system owners with a pre-filled list, specific asks, and a deadline.

*Issue 5: Stale Data*
- Records unverified for months or years (app at v1.5 but actually v3.0).
- Remediation: periodic (e.g., quarterly) verification campaigns — send owners lists to confirm or update, creating accountability and freshness.

*Issue 6: Inconsistent Data*
- Naming conventions broken, status values inconsistent, relationships modeled differently.
- Remediation: enforce standards with dropdowns instead of free text and ServiceNow rules that validate data as entered — make deviation hard.

*Prioritization Framework and Phased Approach*
- High impact + high effort: schedule dedicated effort. High impact + low effort (quick wins, e.g., merging 50 duplicates): do first.
- Low impact + low effort: nice-to-have. Low impact + high effort: skip.
- Phases: 1) identify via dashboard/reports, 2) triage by impact/effort, 3) fix high-impact first, 4) measure progress, 5) govern to prevent regression.

**Action Items**
- Run duplicate detection (naming and owner-based) and merge the top duplicates as an afternoon quick win.
- Produce an orphaned-CI report and triage each record into delete / mark retired / add missing relationships.
- Launch a quarterly verification campaign: email system owners a list of their CIs with a deadline to confirm or correct.
- Replace free-text fields with dropdowns and add validation rules so bad data cannot be entered.
- Build the five-phase remediation loop into a recurring review (e.g., monthly triage, quarterly verification).

**Key Terms/Concepts**
- **Orphan CI**: CI record with no relationships, indicating isolation or obsolescence.
- **Master record**: the canonical CI record kept when merging duplicates.
- **System owner**: the person/team responsible for a component, used to validate relationships and attributes.
- **Verification campaign**: periodic exercise where owners confirm or update CI data to keep it fresh.
- **Impact × effort matrix**: prioritization grid — high-impact/low-effort quick wins first, low-impact/high-effort skipped.

## Chapter 3 — 4. CMDB governance and best practices

**Core Insights**
- Governance is what prevents decay in the first place — policies, processes, and responsibilities that keep the CMDB healthy over time.
- Ownership must exist at two levels: a configuration management team owns the CMDB overall, and each CI has a system/application team owning its accuracy.
- Don't rely on voluntary compliance — enforce standards inside ServiceNow with mandatory fields, dropdowns, business rules, and compliance dashboards.
- Governance evolves along a maturity curve from ad-hoc to optimized; most organizations should target Level 3 (Managed), which delivers reliability without constant firefighting.
- Start simple, iterate: define CI types, mandatory attributes, and naming conventions, enforce them, track metrics, then refine annually.

**Detailed Notes**
*Key Elements of Governance*
- **Clear ownership structure**: a configuration management role/team sets standards and drives improvement; individual CIs have named owners.
- **Standards**: document CI types tracked, mandatory attributes per type, naming conventions, and valid status values; distribute to everyone creating or updating CIs.
- **Enforcement mechanisms**: mandatory fields so critical attributes can't be blank, dropdowns for status, business rules validating relationships, dashboards tracking compliance — make the wrong thing hard and the right thing easy.
- **Process integration**: provisioning auto-creates CIs (via discovery or workflow), decommissioning marks retired, deployments update versions — CMDB updates are part of operational processes, not an afterthought.
- **Ownership and accountability**: use a RACI matrix for CMDB decisions; make clear that keeping CIs updated is part of each owner's job, with consequences when health metrics decline.
- **Regular audits**: periodically (e.g., quarterly) sample CIs and verify existence, location, and ownership against reality; use findings to fix systematic problems.
- **Training and communication**: people can't follow standards they don't know — train teams, share real examples of failures caused by bad data.
- **Continuous improvement**: governance is not static — add CI types for new technologies, refine attribute definitions, review the whole framework annually.

*Governance Maturity Model*
- **Level 1 (Ad-hoc)**: CMDB exists, no clear governance, poor data quality, sporadic updates.
- **Level 2 (Defined)**: basic standards defined, some enforcement, quality improving but gaps remain.
- **Level 3 (Managed)**: governance documented and enforced, ownership clear, health metrics tracked, data quality good — the realistic target for most organizations.
- **Level 4 (Optimized)**: governance fully integrated with processes, continuous improvement, consistently high quality.

**Action Items**
- Publish a CMDB standard document covering CI types, mandatory attributes, naming convention, and valid statuses.
- Turn on mandatory fields, dropdowns, and business rules in ServiceNow so standards are enforced at entry.
- Draft a RACI matrix for the CMDB (responsible/accountable/consulted/informed) and communicate consequences for declining health metrics.
- Run a quarterly sample audit of CIs against reality and use findings to drive systematic fixes.
- Schedule an annual governance review asking: is it working, what are the pain points, what should change; then iterate.

**Key Terms/Concepts**
- **CMDB governance**: the policies, processes, and responsibilities that keep the CMDB healthy over time.
- **Enforcement mechanism**: technical controls (mandatory fields, dropdowns, business rules) that make deviations from standards hard.
- **RACI matrix**: responsibility assignment grid — Responsible, Accountable, Consulted, Informed — applied to CMDB decisions.
- **Governance maturity model**: 4-level progression (Ad-hoc → Defined → Managed → Optimized) describing how mature CMDB governance is.

## Chapter 3 — 5. Demo: CMDB health dashboards and metrics

**Core Insights**
- The ServiceNow CMDB Health dashboard is found via the Application Navigator under "CMDB" — either through the CMDB workspace or directly to the Health dashboard.
- Three views exist: Class (by CI type), Services (by business service), and Health group (by custom groupings like environment or owning team).
- The overall score is a weighted average of the three KPIs — Completeness, Correctness, and Compliance — a headline metric for status reports.
- Each KPI drills down to concrete problem lists: missing mandatory/recommended attributes, duplicate/orphan/stale CIs, and governance audit failures.
- KPIs may show "this KPI has not run" until the scheduled calculation jobs execute — an empty dashboard usually means disabled jobs, not a healthy CMDB.

**Detailed Notes**
*Navigation*
- From the Application Navigator, filter by "CMDB"; either open the CMDB workspace or jump straight to the CMDB Health dashboard.

*Dashboard Views*
- **Class**: health grouped by CI type (server, database, applications...).
- **Services**: health from the perspective of delivered business services.
- **Health group**: health by custom groupings, e.g., all production CIs or CIs owned by a particular team.
- The Configuration Item filter on the Class view shows visibility across all CI types.

*Scores and KPIs*
- **Overall score**: single number, a weighted average of the three KPIs below it; higher is better, moves with data quality.
- **Completeness**: required and recommended attributes populated — drills down to Missing required attributes (most serious) and Missing recommended attributes.
- **Correctness**: accuracy, free of duplicates, orphans, and stale records — three classic integrity problems.
- **Compliance**: CIs failing governance audit rules, e.g., "every production server must have an owner assigned".
- Completeness drops when new CIs arrive incomplete; scores improve when teams populate missing data.

*Reading the State*
- All KPIs showing "this KPI has not run" means the scheduled score-calculation jobs have not executed yet in the instance — the next demo shows how to activate and run them.

**Action Items**
- In a ServiceNow instance, navigate to the CMDB Health dashboard and note which view (Class/Services/Health group) suits your reporting audience.
- Record the overall score and each KPI value as a baseline; identify which CI class drags the score down.
- Check whether any KPI shows "has not run" — if so, verify the calculation schedule jobs are active before trusting the dashboard.
- Set up the Class view with the Configuration Item filter to get cross-CI-type visibility in status reports.

**Key Terms/Concepts**
- **Overall score**: weighted average of Completeness, Correctness, and Compliance KPIs summarizing CMDB health.
- **Correctness**: KPI measuring data accuracy — surfaced through duplicate, orphan, and stale CI lists.
- **Audit section**: compliance list of CIs failing governance rules (e.g., missing required ownership).
- **KPI has not run**: dashboard state indicating the scheduled jobs that compute scores have not executed.

## Chapter 3 — 6. Demo: CMDB health review and correction

**Core Insights**
- Health dashboard KPIs are not computed in real time — scheduled jobs, typically every few hours, calculate and store scores, and the dashboard displays stored results.
- Out-of-the-box, 5 of the 6 CMDB Health schedule jobs are inactive; an empty dashboard is usually "the engine isn't switched on," not a healthy CMDB.
- After activating all jobs and triggering them manually, the instance showed an overall score of 63% — with 295 duplicate computers flagged by Discovery and by Owner.
- Duplicate detection works through two signals: Discovery can't uniquely identify the CI (missing serial/asset tag) and shared owner-defined identifiers.
- Filtering the dashboard to a specific CI class (application servers) recalculates every KPI for that scope (67% overall) — the dashboard localizes where problems live.

**Detailed Notes**
*Score Calculation Architecture*
- Recalculating across thousands of CIs per dashboard open would be too expensive; ServiceNow runs scheduled jobs (typically every 3 hours) that store results the dashboard renders.

*Activating the Jobs*
- Filter Navigator → System Definition → Scheduled Jobs; filter the long list by "name contains health" to find the 6 CMDB Health jobs.
- 5 of the 6 showed active=false — disabled jobs never run despite configured schedules; select all 5 and set active=true.
- To populate the dashboard without waiting up to 3 hours, open each job (e.g., Completeness Score Calculation) and click Execute now.
- A 3-hour schedule is a sensible production default: current enough without straining the platform.

*Interpreting the Results*
- Overall score 63%; Completeness at 100% — every CI in scope has mandatory and recommended fields filled per current rules.
- Correctness: 295 duplicate computers flagged — non-compliant by Discovery (couldn't uniquely identify, often missing serial numbers/asset tags) and non-compliant by Owner (shared owner-defined identifier); printers flagged similarly.
- Orphaned CIs: empty (no isolated records). Stale CIs: service CIs plus 14 Windows cluster nodes not updated recently.
- Compliance audit: 34 service CIs and 13 databases fail governance rules (e.g., missing required ownership or invalid status).

*Scope Filtering*
- Searching "server" and selecting Application Servers recalculates the overall score to 67% with every KPI re-scoped to that class — the dashboard reveals not just overall health but where the problems live.

**Action Items**
- In any ServiceNow instance, verify all six CMDB Health schedule jobs are active before trusting the dashboard.
- After enabling jobs, trigger each one manually with "Execute now" to populate KPIs without waiting for the schedule.
- Review Correctness lists for the two duplicate signals (Discovery-identified and owner-identified) and plan merges.
- Use the Compliance audit section to drive fixes for failing CIs (e.g., missing ownership, invalid status).
- Compare per-class scores against the overall score to locate the CI types with the worst health.

**Key Terms/Concepts**
- **Scheduled job**: platform job that periodically computes and stores dashboard KPI scores (default ~3 hours).
- **Non-compliant by Discovery**: duplicate flag when Discovery cannot uniquely identify CIs, typically missing serial numbers or asset tags.
- **Non-compliant by Owner**: duplicate flag when records share the same owner-defined identifier.
- **Execute now**: manual trigger that runs a scheduled job immediately (used to populate dashboards without waiting).
- **Stale CI**: record not updated or verified recently (e.g., Windows cluster nodes flagged in the demo).