Use PDIs? Take our 5-minute survey to help shape the PDI roadmap.

Formula based KRI on Metric Definitions and calculated threshold

Amrita Kanungo2
Tera Contributor

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?

6 REPLIES 6

Chetna_Aggarwal
Tera Contributor

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.
  • 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.

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.

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

Tanushri
Tera Contributor

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!