CIs being evaluated is not the same in CMDB Workspace Health Dashboard

FriendlyDude · ‎08-06-2025

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?

AJ-TechTrek · ‎08-07-2025

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

View solution in original post

Mark Manders · ‎08-06-2025

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

AJ-TechTrek · ‎08-07-2025

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