Formula based KRI on Metric Definitions and calculated threshold

[Amrita Kanungo2]

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?

[VJ_Srivastava]

Hello Amrita,

From an enterprise architecture and platform scalability perspective, relying heavily on Scripted Metric Definitions inside the GRC/IRM module to calculate complex percentages and time-series trends is an architectural anti-pattern. As your instance scales and transaction volumes grow, heavy GlideRecord/GlideAggregate scripts running via scheduled metric collections can introduce significant performance bottlenecks.

To build a resilient, scalable risk architecture, I strongly recommend leveraging Performance Analytics (PA) to handle the data processing, rather than scripting directly in IRM:

• Decoupled Analytical Processing: Performance Analytics is natively designed to handle complex aggregates (like formula-based percentages for unsuccessful changes) and historical time-series comparisons (evaluating if this month's incidents are higher or lower than last month's).

• PA to GRC Integration: ServiceNow IRM natively supports PA Metric definitions. You can configure your Formula Indicators and Time Series configurations entirely within PA, and then simply map your GRC KRIs to consume those PA Indicators.

By abstracting the heavy data crunching to the analytics engine, you keep your core transactional database highly performant, reduce technical debt, and ensure your risk infrastructure remains robust as your IT footprint scales.

[Tanushri]

Hi Prudhvipotr,

This is a notorious friction point when organizations try to bridge legacy backend processes with the modern Service Portal framework. The root cause of the "0 Questions / Blank Survey Page" and the authorization errors boils down to a fundamental schema incompatibility.

The out-of-the-box Employee Center take_survey widget is hardcoded to query the modern Assessment engine tables (specifically asmt_assessment_instance, asmt_metric_type, and asmt_metric). It simply does not know how to read or render the legacy assessment_master or survey_question tables.

Here is the technical breakdown of your options:

1. The "Band-Aid" Fix (Not Recommended): If you absolutely cannot migrate off the legacy engine today, you cannot use the take_survey widget. Instead, you would need to redirect the user to the classic UI page wrapper. In your Record Producer script, you would construct a redirect URL pointing to the old processor, such as: producer.portal_redirect = "?id=form&table=assessment_master... " or use an iframe widget to render assessment_take2.do. This often results in a poor, non-responsive UI experience on the portal.

2. The Platform-Native Fix (Highly Recommended): The CreateAssessment() API failures and widget blank pages are the platform's way of telling you these technologies are decoupled. You need to migrate your Risk Assessment from the legacy assessment_master framework to the modern Assessment Metrics (asmt_metric_type) framework.

   • Once you recreate the questions in the modern engine, the system will natively generate the asmt_assessment_instance records.

   • The take_survey widget will instantly recognize the instance, render the questions beautifully without authorization errors, and you can simply use the native OOB UI Actions or standard Record Producer redirects to pass the sys_id into the portal URL (e.g., /esc?id=take_survey&instance_id=YOUR_NEW_INSTANCE_SYS_ID).

Stop fighting the Service Portal framework with Business Rules meant for a deprecated engine—migrating the data to the new schema is the only sustainable technical path forward!