⬡ Part 7 · Topic 6
Foundation Dashboards & CMDB 360 — Executive Visibility into CMDB Program Health
The previous topic covered how individuals access CMDB data through Workspace and NLQ. This topic covers how organizations track the overall health and completeness of their CMDB program through Foundation dashboards and the CMDB 360 report. These tools answer the executive-level question: "Is our CMDB good enough to trust?" They connect data quality metrics to governance accountability across all the technical layers we've built in this course.
Section 1
Foundation Data — The Non-Negotiable CMDB Core
Before discussing dashboards, it's critical to understand what "foundation data" means in CMDB context. Foundation data is the minimum set of CI attributes and relationships that must be populated for the CMDB to deliver value to ITSM processes.
Foundation data is not everything in the CMDB — it is the essential subset that other processes depend on. ServiceNow defines foundation data as the set of information needed for CMDB to be useful, not merely populated.
Foundation Data Categories
- CI Identification data: The fields used by Identification Rules to uniquely identify CIs. Without correct identification data, duplicates form and IRE fails.
- CI Ownership data: support_group, owned_by, managed_by — the fields that enable correct incident routing, change approval, and SLA assignment.
- CI Classification data: sys_class_name, location, environment, operational_status — the fields that enable filtering, scoping, and impact assessment.
- CI Relationship data: The connections between CIs (cmdb_rel_ci) that enable impact analysis, service mapping, and CSDM dependency chains.
- CSDM links: Connections from infrastructure CIs up through Application Services to Business Applications — required for change impact analysis and incident prioritization.
Analogy — Foundation Data as a Building's Structural Framework
A building can have beautiful interiors, marble floors, and ornate decor — but if
the structural framework (foundation, load-bearing walls, roof beams) is missing
or compromised, none of the decorative work matters. Foundation data is the CMDB's
structural framework. Everything else (custom fields, extended attributes, enriched data)
is decoration. Start with the foundation; add detail progressively.
Section 2
Foundation Dashboards — Program-Level Health Reporting
ServiceNow provides pre-built Foundation Dashboards that aggregate CMDB Health scores and program metrics across CI classes, teams, and service domains. These are the dashboards that CMDB Managers use for governance reporting to IT leadership.
Key Foundation Dashboard Views
- CMDB Health by CI Class: Overall health score per class. Sortable. Shows which classes have the most data quality issues. Color-coded (green/yellow/red).
- Health Trend Over Time: Line chart showing how aggregate CMDB health has changed over weeks/months. Used to demonstrate governance program impact.
- Top Issues List: The specific failing Health Rules with the highest CI-count impact. "1,847 server CIs missing support_group" — ranks issues by scope.
- Coverage by Discovery Source: What percentage of each CI class is being populated by which discovery sources. Identifies coverage gaps — "22% of network devices have no discovery source (manually created, never verified)."
- CSDM Completeness: What percentage of Business Applications have linked Application Services. What percentage of Application Services have linked infrastructure CIs. Measures the service model completeness across all CSDM domains.
- Duplicate Rate: CI-class level duplicate percentages from the Deduplication system. Target: <1% across all classes.
Key Concept — Foundation Dashboards Are for Program Management, Not Day-to-Day Operations
Foundation Dashboards answer: "How is our CMDB program doing overall?"
CMDB Workspace / CI 360 answers: "What is wrong with this specific CI?"
These are different questions for different audiences. CMDB Manager uses
Foundation Dashboards for monthly governance reviews. Data Stewards use
CMDB Workspace for daily operational work. Both are needed; neither replaces the other.
Section 3
CMDB 360 — The Service Model Completeness View
CMDB 360 is a specific report/view that shows the completeness of the service model across CSDM domains. While CMDB Health scores measure individual CI data quality, CMDB 360 measures whether the connections between CIs and the CSDM service layers are properly established.
Think of it this way: CMDB Health says "this CI has good data." CMDB 360 says "this CI is properly connected into the service model so it contributes to Change Impact Analysis and Business Application health tracking."
What CMDB 360 Measures
- Business Application ↔ Application Service links: Are Business Applications (Domain 1) linked to their technical Application Services (Domain 2)? Orphaned Business Applications can't propagate impact or receive automated criticality scoring.
- Application Service ↔ Infrastructure CI links: Are Application Services connected to the CIs they depend on (Domain 4)? Without this, Service Mapping is incomplete and incident correlation fails.
- Technical Service ↔ consuming services: Are Technical Services (shared infrastructure like DNS, Active Directory) linked to the Application Services that consume them?
- CI ↔ Business Application traceability: For any given infrastructure CI, can ServiceNow trace a path to a Business Application? If not, the CI is "orphaned" in CSDM terms — its failure has no visible business impact.
Exam Pattern — CMDB 360 vs. CMDB Health
CMDB Health = data quality of individual CIs (completeness, correctness, staleness).
CMDB 360 = completeness of the service model (are all CSDM connections made?).
A CMDB can have high Health scores (all CIs have great data) but low CMDB 360 scores (none of the CIs are connected into Application Services). Both are required for a fully functional CMDB that delivers value to ITSM processes.
CMDB 360 = completeness of the service model (are all CSDM connections made?).
A CMDB can have high Health scores (all CIs have great data) but low CMDB 360 scores (none of the CIs are connected into Application Services). Both are required for a fully functional CMDB that delivers value to ITSM processes.
Section 4
Building Custom CMDB Reports
Beyond pre-built Foundation Dashboards and CMDB 360, ServiceNow's standard Report Builder can create custom CMDB reports. These are regular ServiceNow reports created against CMDB tables.
Common Custom CMDB Reports
- CIs by support_group: How many CIs does each support group own? Useful for capacity planning and workload balancing.
- CIs by discovery source: Which tool is responsible for discovering each CI class? Identifies gaps in discovery coverage.
- Stale CIs by class and owner: CIs not discovered in 30/60/90 days, grouped by support_group. Sends accountability to the right team.
- CSDM gap report: Business Applications with no linked Application Service. Application Services with no linked CIs. Orphan CIs with no CSDM connection.
- Integration source quality report: Per integration source (Discovery, SGC, SCCM), CI count, staleness rate, completeness rate, duplicate rate. Used for Integration Owner accountability.
Scheduled Reports for Governance
Custom reports can be scheduled to run automatically and email results to stakeholders. Key scheduled governance reports:
- Weekly: Stale CI report to Data Stewards by CI class
- Monthly: Integration source quality report to Integration Owners
- Quarterly: CMDB Health trend report to CMDB Manager and CMDB Owner
- On-demand: CSDM completeness report before major change windows
Section 5
Connecting Dashboards to Governance Accountability
Dashboards and reports only create value when they are connected to accountability. A score that nobody is responsible for improving is just a number. The CMDB governance roles (from Part 6 Topic 5) map to specific dashboard responsibilities:
| Role | Dashboard / Report Used | Accountability |
|---|---|---|
| CMDB Owner | Foundation Dashboard overview; CMDB Health trend; CSDM completeness summary | Overall CMDB program health. Escalates when scores fall below threshold. Reports to CIO. |
| CMDB Manager | All Foundation Dashboards; CMDB 360; Health Trend; Issue prioritization | Interprets scores, assigns remediation tasks, drives quarterly governance review. |
| Data Steward | CMDB Health by CI class (their class); Top Issues; Drill-down to specific failing CIs | Owns completeness, compliance, and correctness for their CI class. Accountable for class-level Health scores. |
| Integration Owner | Discovery source coverage report; integration quality report; staleness by source | Accountable for data quality of CIs populated by their integration source. |
| CMDB Architect | CMDB 360 service model completeness; Deduplication dashboard; Identification rule effectiveness | Technical design accountability. When structural issues cause quality problems, architect proposes fixes. |
Tip — Build Dashboards INTO Governance Meetings, Not Separately
The most effective CMDB programs use dashboards as the agenda for governance meetings.
The monthly CMDB governance meeting opens the Foundation Dashboard, reviews scores,
identifies owners of red/yellow items, and assigns remediation tasks with deadlines.
The score trend chart at the next meeting shows whether assignments were completed.
This creates a feedback loop: dashboards → accountability → action → improved scores.
Section 6
Putting It All Together — The CMDB Program Loop
Now that you've studied all the topics in this course, here's how they connect into a continuous improvement loop:
The CMDB Program Continuous Improvement Loop
- Ingest: Discovery, SGC, and integrations populate CI data into the CMDB through IRE (identification, reconciliation, deduplication).
- Measure: CMDB Health scores measure data quality across five dimensions. CMDB 360 measures service model completeness. Foundation Dashboards aggregate both into program-level metrics.
- Identify issues: Health Dashboard drill-down identifies specific failing CIs and failing Health Rules. Source Attribution in CI 360 identifies which source caused the problem.
- Assign accountability: Governance roles (Data Steward, Integration Owner, CMDB Architect) are assigned to remediate based on the root cause.
- Remediate: Fix the root cause (bad Identification Rule → fix the rule; bad Discovery coverage → fix the schedule; missing CSDM link → use Service Mapping or manual link; wrong class → reclassify through the Data Steward process).
- Verify: Re-run Discovery, re-score Health, check that CMDB 360 completeness improved. Validate the fix didn't introduce new issues.
- Report: Health trend dashboards show improvement over time. Governance meeting reviews scores. CMDB Owner reports program health to CIO.
- Return to step 1: Continuous operation, continuous measurement, continuous improvement. The CMDB is never "done" — it requires ongoing governance.
Key Concept — Why GOVERN Is 35% of the Exam
Technical tools (Discovery, IRE, SGC) solve the data ingest problem.
The CMDB Health, CMDB 360, and Foundation Dashboards solve the measurement problem.
But without governance (roles, accountability, processes, policies), the measurements
never translate into sustained improvement. Any organization can get data into the CMDB;
keeping it accurate over time requires governance. That's why GOVERN dominates the exam —
it's the hardest part to implement and the part most organizations get wrong.
Section 7
Maturity Indicators from Dashboard Patterns
Experienced CMDB practitioners can read program maturity from dashboard patterns. The exam may present scenarios that require you to identify what stage of maturity an organization is at and what its next priority should be:
| Dashboard Pattern Observed | Maturity Diagnosis | Priority Next Step |
|---|---|---|
| High duplicate rate across all classes; low Correctness scores | Reactive / Level 0-1: Identification Rules misconfigured or missing; multi-source without reconciliation | Audit and fix Identification Rules; configure Reconciliation Rules; run Deduplication |
| Good Health scores for core classes; CMDB 360 shows 30% CSDM completeness | Defined / Level 2: Technical data quality improving but service model not built out | Implement Service Mapping for critical applications; manually link Business Applications to Application Services |
| All Health scores 80+; CMDB 360 completeness 85%; Staleness increases quarterly | Managed / Level 3: Good baseline data; discovery coverage gaps growing as infrastructure changes faster than discovery keeps up | Expand Discovery coverage (new subnets, cloud regions); implement CI Group-based Discovery for high-churn environments |
| All KPIs consistently green; CMDB 360 95%+; Health trend stable or improving each quarter | Optimized / Level 4: Program is mature; focus shifts to proactive governance and business value demonstration | Automate reporting to business stakeholders; use CMDB data to drive IT financial management and risk analysis |
Exam Quick Reference
Foundation Dashboards & CMDB 360 — Key Facts
- Foundation data = minimum CI attributes and relationships needed for CMDB to deliver ITSM value. Categories: identification, ownership, classification, relationships, CSDM links.
- Foundation Dashboards = program-level health reporting: Health by CI class, Health trend, Top Issues, Discovery coverage, CSDM completeness, Duplicate rate. For CMDB Manager and CMDB Owner.
- CMDB 360 = service model completeness report. Measures whether CSDM connections (CI → Application Service → Business Application) are complete. Distinct from CMDB Health (individual CI data quality).
- CMDB Health (individual CI quality) + CMDB 360 (service model completeness) = both required for full CMDB program value.
- Custom reports can be built with Report Builder against any CMDB table and scheduled for automated delivery to stakeholders.
- Dashboards → Governance accountability = each score must have an owner responsible for improving it. Without accountability, scores are just numbers.
- The CMDB program loop: Ingest → Measure → Identify → Assign → Remediate → Verify → Report → repeat.
- GOVERN is 35% of exam because technology solves the ingest problem; governance solves the sustained quality problem.
Term Grid
Foundation Data
The minimum set of CI attributes and relationships required for the CMDB to deliver value to ITSM processes. Includes identification fields, ownership fields, classification fields, relationships, and CSDM service model links.
Foundation Dashboard
Pre-built ServiceNow dashboard aggregating CMDB Health scores and program metrics across CI classes, discovery sources, and service domains. Used by CMDB Manager for governance reporting.
CMDB 360 Report
ServiceNow report measuring service model completeness across CSDM domains. Tracks: Business Applications with linked Application Services, Application Services with linked CIs, orphan CIs with no CSDM connection. Distinct from CMDB Health (individual CI quality).
CSDM Completeness
The degree to which CSDM connections are established throughout the service model hierarchy. Measured by CMDB 360. High CSDM completeness = reliable change impact analysis and business application health visibility.
Orphan CI
A CI with no upward connection in the CSDM service model hierarchy — not linked to any Application Service or Business Application. Its failure has no visible business impact in ServiceNow. Must be linked or accepted as excluded from service model.
Program Health Loop
The continuous CMDB improvement cycle: Ingest → Measure (Health/CMDB360) → Identify Issues → Assign Accountability → Remediate → Verify → Report → repeat. Governed by CMDB governance framework. Never finishes — CMDB requires ongoing maintenance.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. A CMDB program shows CMDB Health scores of 88% overall (Green) across all major CI classes. However, the CMDB Manager reports that Change Impact Analysis is still failing — changes to database servers routinely trigger unexpected outages to business applications that weren't in the change record. What is the most likely problem and what tool surfaces it?
💡 High CMDB Health but failing change impact analysis — what's the difference between data quality and service model completeness?
Answer: B — This is the classic "high Health, broken impact analysis" scenario. CMDB Health measures individual CI data quality (fields populated, correct values, no duplicates) — the CIs look great individually. But Change Impact Analysis works by traversing the CSDM relationship chain: CI → Application Service → Business Application. If Application Services aren't linked to the database server CIs (low CMDB 360 / CSDM completeness), the impact chain is broken regardless of how good individual CI data quality is. The fix: use Service Mapping to build proper Application Service maps connecting CIs to business applications.
2. During a quarterly CMDB governance review, the Foundation Dashboard shows that the Staleness health score for the "cmdb_ci_win_server" class dropped from 82% (Green) to 48% (Red) this quarter. The Completeness, Compliance, and Correctness scores are all stable. What is the most appropriate first response?
💡 Sudden staleness drop for one class, stable other dimensions — what does this pattern suggest about the root cause?
Answer: B — A sudden, class-specific staleness drop (from 82% to 48%) while other dimensions remain stable is the signature pattern of a Discovery configuration failure. Other dimensions are fine because the CI records still exist and still have good data — but last_discovered timestamps stopped updating because Discovery stopped running for Windows servers. First step: investigate Discovery configuration changes this quarter (credential rotation? MID Server upgrade? Schedule modification? Firewall rule change?). Options A and D (retiring/archiving stale CIs) are premature — the CIs may not actually be decommissioned, just undiscoverable due to a configuration issue. Option C (adjusting the threshold) hides the problem without fixing it.
3. A new CMDB Manager wants to demonstrate CMDB program value to the CIO. Which combination of dashboard metrics tells the most complete story of program health?
💡 A CIO wants program health, not just raw counts. What combination captures both data quality and business model completeness?
Answer: B — The most complete CMDB program health story combines: (1) CMDB Health scores across all five dimensions show that individual CI data is accurate, complete, current, compliant, and deduplicated; (2) the trend over two quarters shows whether the program is improving (demonstrates governance is working); (3) CMDB 360 completeness shows the service model is properly built, enabling change impact analysis; (4) duplicate rate shows the ingestion pipeline is under control. Option A (raw record count + schedule count) measures activity, not quality. Option C (incident metrics) is a ITSM metric, not a CMDB quality metric. Option D (cost per CI) is a financial metric, not a quality metric.
4. A CMDB program dashboard shows: Health scores 85%+ across all classes, CMDB 360 completeness 88%, Duplicate rate <0.5%, but Staleness is increasing quarter-over-quarter for cloud VM classes (from 78% to 71% to 63%). All other classes are stable. What is the most appropriate governance response?
💡 Cloud VMs use a specific discovery mechanism. Who is accountable for cloud CI data quality?
Answer: B — Cloud VMs are typically discovered by Service Graph Connectors (SGC) for AWS/Azure/GCP, not traditional IP-based Discovery. A gradual, class-specific staleness decline for cloud VMs suggests: new cloud regions or accounts are being added (business is expanding cloud footprint) but SGC hasn't been configured for those new regions/accounts. The Integration Owner for cloud is accountable for ensuring SGC coverage matches the actual cloud infrastructure. This is a governance response: assign the Integration Owner to audit SGC configuration against the cloud account inventory. Option A ignores a real and worsening trend. Option C hides the problem. Option D would retire active cloud VMs that are simply in uncovered regions.
5. An organization has: 10,000 CI records, CMDB Health overall 71% (Yellow), CMDB 360 service model completeness 28%, and an ongoing duplicate rate of 4.2%. The CMDB Manager must prioritize which single problem to address first. What is the correct priority order and reasoning?
💡 Consider dependencies: which problem, if left unfixed, makes the other two harder or invalidates the work done on them?
Answer: B — Fix duplicates first. A 4.2% duplicate rate means roughly 420 CIs have duplicate records. If you build CSDM service model links now (Application Services linked to CIs), those links will be attached to the wrong CI record after deduplication merges duplicates — the merged CI may be a different record (the Master), breaking all the relationships you just built. The principle: fix foundational problems before building on top of them. Deduplication → then improve Health (Completeness, Correctness) → then build CSDM service model links. Building the service model on a deduplicated, high-quality foundation ensures the work doesn't need to be repeated. Option A starts with the most complex layer (CSDM) before the foundation (dedup) is stable.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
Foundation Dashboards & CMDB 360 Quiz
1 / 4
CMDB Health shows all CI classes at 88%+ (Green). Yet Change Impact Analysis is failing — changes routinely trigger unexpected outages. What additional metric would explain this, and what tool surfaces it?
💡 Explanation
B is correct. CMDB Health and CMDB 360 measure different things. CMDB Health measures individual CI data quality (are fields complete, correct, compliant, current, deduplicated?). CMDB 360 measures service model completeness (are CIs connected upward through the CSDM chain to Application Services and Business Applications?). Change Impact Analysis traverses the CSDM relationship chain — if that chain is broken (low CMDB 360), impact analysis fails even if every individual CI has perfect data quality. High CMDB Health + low CMDB 360 is the classic scenario where "the data is great but the model is missing."