Adding Previous Value To Metrics To Track Process Flows

With a small modification to ServiceNow metrics, we can track the flow of tasks between groups and states and create reports to analyze it.

If you’re not familiar with metrics in ServiceNow, they are a great feature allowing you to capture data that would otherwise be unavailable for reporting. You can use metrics to capture duration information about any field in a record, like for example the duration of an assignment or task state. Metrics work by creating instances of metric definitions when a certain condition is met. The creating of the instance can also be triggered by a business rule.

Out-of-the-box metric instances can only capture and hold one value. In this post, we will be looking at how to extend that to capture both the current and previous value of a field. This will allow us to report on the volume of flows. More specifically, we will try to visualize which groups are sending and receiving tasks from each other. This can be valuable information to gain instance into the operations of your business and the workings of your processes.

Adding the Field to Hold the Previous Value

First we need to add a field to our metric instances to hold the previous value. The new field is called “Previous Value” and is a string with a length of 100:

Creating the Metric Definition

Next we need to create a metric definition. This metric definition will not create metrics in itself, neither by field changes or script. But we need a definition if we want to create metrics. We want to track thee assignment group flow of all tasks, so we set the table to [task]. They type will be “Script calculation”, but we’ll leave the script field blank. As for the field, it needs to be set to “Assignment Group”:

Business Rule

We now have a field to hold our value, and a metric definition to create instances of. Now we need a business rule to trigger the instance creation and fill in the values.

The Business Rule should run on the [task] table before inserts or updates. In the conditions, we specify that for the rule to run, the value of assignment group has to change:

On the advance tab, we’ll set the script to the following. Don’t forget to change the definition variable to the sys_id if you metric definition:

(function executeRule(current, previous /*null when async*/) {
	var definition = '8219db7107df2010da6cff4c7c1ed022';
	var mi = new MetricInstance(definition, duration, current, previous);
	var nr = mi.getNewRecord(); = current.getUniqueValue();
	nr.definition = definition;
	nr.field = 'assignment_group';
	nr.field_value = current.assignment_group.getValue();
	nr.u_previous_value = previous.assignment_group.getValue();
	nr.start = current.getValue('sys_created_on');
	nr.end = current.getValue('sys_updated_on');
	var duration = gs.dateDiff(nr.start,nr.end);
	nr.calculation_complete = true;
})(current, previous);

This will set the field value to the new assignment group, and the previous value to the old assignment group. The start field will contain the date-time the task was created on, while the end will contain the date-time of the change of assignment group. Based on these two fields, the duration will be calculated. This means that the duration field will contain the time of the assignment compared to the time the task was created. So not only can we see what group sent a task to another group, but how long into the task lifecycle that assignment happened.

The result is metric instances being created for each reassignment of the task. In the image below, we can see an incident was sent from the network group to the database group, and then finally to the service desk group.

Database view

The metric_instance record does not have a reference field to the task table. The “ID” field in the instance which contains the value of our task is a “document_id” type field. This does not allow us to dot-walk. So to support reporting, we should set up a database view. If you’re just looking to report on incidents, there is one out of the box called “incident_metric”. However, we want to report on all task types, so we’ll set up a new view where we left join the [task] table to the metric instances:

Creating the Performance Analytics Components

We have our data setup and it’s time to move on to the PA components needed to report on inputs and outputs for a group.

First we’ll need a indicator source. The table for the source needs to our new database view, with a the filter:

  • Definition is “Assignment Group Flow”
  • [metric_instance].Created on Today

We also need breakdowns for sending and receiving groups. We can base these breakdowns on the “Groups” breakdown source. The sending group breakdown needs to be mapped to the “previous value” field of our database view:

While the receiving group breakdown needs to be mapped to our “field value” field of our view:


With our indicator source and breakdown set up, we can start creating indicators. Some suggested indicators are:

  • Number of assignments
  • Number of distinct tasks assigned
  • Average age (duration) of task when assigned
  • Number of assignments per hour of day (bucket breakdown on “sys_created_on”)
  • Number of assignments where reassignment count is more than 5
  • Number of tasks by first assignment group (previous value is empty)

By creating these indicators, and adding both breakdowns for sending and receiving group, we will be able to analyze or flow of tasks between groups. For example we could select the service desk group and see which groups receive tasks that the first line cannot resolve themselves. If a group receives a lot of old tasks whose SLAs have already breached, we will be able to see which groups are sending these tasks. We can also combined data from the tasks, to look at things like which groups receive high priority incidents. By leveraging the reassignment count field in filters and breakdowns, we will be able to see which groups are bouncing around tasks in an ineffective process flow.


Here is an example of a dashboard using indicators based on our metric data. The dashboard has a breakdown source, and the widgets are set to follow this source for either sending group or receiving group. In the image below, we are analyzing the task flows to and from the service desk group:

Leave a Reply

Your email address will not be published. Required fields are marked *