- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2025 04:13 AM
Hi,
Back when we are still CMDB Health Dashboard in Washington DC to Monitor triple Cs, we are getting the same number of CIs being evaluated for each KPI. However, in Yokohama we are now encouraged to use CMDB Workspace to monitor triple Cs. I can see that the number of CIs being evaluated is different for each KPI. What could be the explanation for that?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Hi @FriendlyDude ,
Root Cause & Explanation:
In Washington DC and earlier, the CMDB Health Dashboard used a common CI evaluation scope across all three KPIs — meaning all CIs from the configured health inclusion rules were evaluated uniformly across Completeness, Correctness, and Compliance.
However, starting in Yokohama, with the transition to CMDB Workspace, each KPI now:
Evaluates CIs independently
Based on its own health metric rules and CI applicability
Applies different filters or applicability conditions per metric under the hood
What This Means:
KPI | CI Count Difference Reason |
Completeness | Only includes CIs where mandatory fields (like name, serial number, etc.) are expected and measurable |
Correctness | CIs must have detectable data accuracy issues (e.g., duplicates, orphaned records) |
Compliance | Only evaluates CIs against configured policies or internal standards (e.g., OS version, patch levels) |
Thus, even if all 3 KPIs appear to evaluate the same class (like cmdb_ci_computer), the actual CIs they each process may differ.
Suggested Actions:
1. Review the Health Metric Definitions:
* Navigate to: CMDB Health > Metric Definitions
* Check each metric’s filter conditions and applicability rules.
* Pay attention to Exclusion Rules, especially for user-defined classes or specific CIs.
2. Check the Health Inclusion Rules:
* Navigate to: CMDB Health > Health Inclusion Rules
* Make sure CIs are included consistently if that’s the desired behavior.
3. Use the Triple C Monitor Page:
* In CMDB Workspace, use the Triple C Monitor view
* It gives better visibility into why CIs are excluded for certain KPIs.
Additional Notes:
* This behavior is by design in Yokohama onwards to give more granular and meaningful CI evaluations.
* If you want to revert to consistent CI evaluation across KPIs, you'd need to align filters and applicability for each metric manually — not generally recommended unless for a specific use case.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2025 04:18 AM
And which was/is wrong? Have you checked on the logic that is generating those numbers as output?
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a month ago
Hi @FriendlyDude ,
Root Cause & Explanation:
In Washington DC and earlier, the CMDB Health Dashboard used a common CI evaluation scope across all three KPIs — meaning all CIs from the configured health inclusion rules were evaluated uniformly across Completeness, Correctness, and Compliance.
However, starting in Yokohama, with the transition to CMDB Workspace, each KPI now:
Evaluates CIs independently
Based on its own health metric rules and CI applicability
Applies different filters or applicability conditions per metric under the hood
What This Means:
KPI | CI Count Difference Reason |
Completeness | Only includes CIs where mandatory fields (like name, serial number, etc.) are expected and measurable |
Correctness | CIs must have detectable data accuracy issues (e.g., duplicates, orphaned records) |
Compliance | Only evaluates CIs against configured policies or internal standards (e.g., OS version, patch levels) |
Thus, even if all 3 KPIs appear to evaluate the same class (like cmdb_ci_computer), the actual CIs they each process may differ.
Suggested Actions:
1. Review the Health Metric Definitions:
* Navigate to: CMDB Health > Metric Definitions
* Check each metric’s filter conditions and applicability rules.
* Pay attention to Exclusion Rules, especially for user-defined classes or specific CIs.
2. Check the Health Inclusion Rules:
* Navigate to: CMDB Health > Health Inclusion Rules
* Make sure CIs are included consistently if that’s the desired behavior.
3. Use the Triple C Monitor Page:
* In CMDB Workspace, use the Triple C Monitor view
* It gives better visibility into why CIs are excluded for certain KPIs.
Additional Notes:
* This behavior is by design in Yokohama onwards to give more granular and meaningful CI evaluations.
* If you want to revert to consistent CI evaluation across KPIs, you'd need to align filters and applicability for each metric manually — not generally recommended unless for a specific use case.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025