Formula based KRI on Metric Definitions and calculated threshold
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
I have 2 requirements and I need some suggestions here as to how to best achieve it
1. Build a Metric definition based on calculation of % of unsuccessful changes - Formula - Total closed Unsuccessful Changes / Total closed changes * 100
How to achieve this? Any way we can use Calculated metric definition for it? If so can you please guide on the process? Or we can use scripted metric definition?
2. Build a Metric definition to show number of incidents created as a result of change, the filter is straight forward but for the threshold the requirement is to have 3 values - Increasing, Decreasing and Stable and the logic is Increasing will be based on last month data, same for decreasing based on last month and stable meaning no change.
Anyone having any experience with these requirements?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
1. % of Unsuccessful Changes
Formula:
(Total Closed Unsuccessful Changes / Total Closed Changes) × 100
A standard Metric Definition is not the best fit because metric definitions capture durations or events on individual records, not aggregate calculations across multiple records.
A better approach would be:
- Performance Analytics (Recommended):
- Create two Automated Indicators:
- Total Closed Changes
- Total Closed Unsuccessful Changes
Create a Formula Indicator:
(Unsuccessful Closed Changes / Total Closed Changes) * 100- This gives you historical trends, scorecards, and dashboards.
- Create two Automated Indicators:
- If you don't have Performance Analytics:
- Create a scheduled script that calculates the percentage and stores the result in a custom table for reporting.
- Alternatively, use a scripted report.
I would not recommend a Metric Definition for this requirement.
2. Incidents Created as a Result of Change
This can be achieved more easily.
Create an indicator or report that counts incidents where:
- Caused by Change = True (or your relationship field)
- Group by month
Then compare the current month's count with the previous month's count.
Threshold logic:
- Increasing → Current Month > Previous Month
- Decreasing → Current Month < Previous Month
- Stable → Current Month = Previous Month
If you're using Performance Analytics, configure a Direction Threshold by comparing the latest score with the previous score. PA supports trend comparisons like this out of the box.
If you're not using PA, a scheduled script can compare monthly values and update a status field (Increasing/Decreasing/Stable) for reporting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
The requirement is to have metrics created in GRC built for KRI and KCI to indicate threshold colours against those range of values. They already have the first one implemented as an indicator. The ask is for GRC Metrics for KRI to be created for this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi @Amrita Kanungo2,
1. You can either use Automated Scripted metric definitions or Calculated metric definitions. My recommendation is to use Calculated metric definitions. I am assuming Total closed Unsuccessful Changes and Total closed changes are other metric definitions.
2. You can create thresholds on any type of metric definition - https://www.servicenow.com/docs/r/environmental-social-governance/thresholds-for-metrics.html
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Amrita,
This is a fantastic initiative. From a business strategy standpoint, shifting from qualitative risk assessments to automated, data-driven Key Risk Indicators (KRIs) is exactly how mature organizations protect their bottom line and drive operational excellence.
When you implement these specific metrics, you are delivering direct value to both IT and business stakeholders:
Protecting Business Continuity: Tracking the percentage of unsuccessful changes and the incidents they cause directly measures the maturity of your release pipelines. Every incident caused by a botched change represents operational downtime, decreased employee productivity, and a potential hit to customer trust.
Actionable Intelligence over Static Data: Your second requirement—categorizing the risk as Increasing, Decreasing, or Stable—is incredibly strategic. Static numbers rarely tell the whole story. By surfacing trends, you transform raw data into actionable intelligence. If leadership sees an "Increasing" trend in change-related incidents, they can proactively pause feature releases and enforce stricter governance before a catastrophic systemic failure occurs.
Automating these dynamic thresholds ensures your risk managers spend less time manually compiling audit spreadsheets and more time strategically advising the business on how to move fast without breaking things. Great work identifying these critical indicators!