Add course notes: ServiceNow CMDB Fundamentals 2026 (22 videos, 3 chapters)

knowledgebase/course-notes/ServiceNow-CMDB-Fundamentals-Notes.md

@@ -0,0 +1,805 @@
+# 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).