Unlocking Sequential Data Analysis in ServiceNow: Comparing Previous and Current Records in GlideRecord Queries

For ServiceNow developers, the GlideRecord object is the workhorse for interacting with data. Often, you might encounter scenarios where you need to analyze records sequentially within a query, comparing the current record to the one that came before it. This pattern is common when calculating trends, identifying changes over time, or performing other forms of sequential data analysis within your ServiceNow instance. However, directly comparing "previous" and "current" records in a GlideRecord iteration can be trickier than it initially seems. This article will illuminate the common pitfalls and provide a reliable method to effectively compare consecutive records in your ServiceNow GlideRecord queries.

The challenge arises from how GlideRecord handles object references. When you iterate through a GlideRecord query and attempt to store a record as the "previous" one, you might find that in subsequent iterations, both your "previous" and "current" variables point to the same record. This is because assigning a GlideRecord object to another variable in JavaScript creates a reference to the same underlying data, not an independent copy.

Let's illustrate this with a simplified example. Suppose you want to iterate through a list of incidents ordered by their creation date and compare the priority of each incident with the one created immediately before it. A naive approach might look something like this:

JavaScript

var incidentGR = new GlideRecord('incident');
incidentGR.orderBy('sys_created_on');
incidentGR.query();

var previousIncident = null;
while (incidentGR.next()) {
  var currentIncident = incidentGR;
  if (previousIncident) {
    gs.info('Current Incident Number: ' + currentIncident.number + ', Priority: ' + currentIncident.priority);
    gs.info('Previous Incident Number: ' + previousIncident.number + ', Priority: ' + previousIncident.priority);
    // Comparison logic here
  }
  previousIncident = currentIncident;
}

If you were to run this script, you would likely find that within the if (previousIncident) block, both currentIncident and previousIncident refer to the same incident record in each iteration (after the first one). This is because previousIncident = currentIncident; is assigning a reference to the same GlideRecord object that incidentGR is currently pointing to.

The Solution: Capture Field Values, Not the Object Reference

The key to accurately comparing previous and current records in a GlideRecord query is to store the specific field values you need for comparison, rather than trying to store the entire GlideRecord object itself. You can achieve this by using the getValue() method to retrieve the values of the relevant fields from the "previous" record and store them in separate variables or an object.

Here's how you can modify the previous example to correctly compare incident priorities:

JavaScript

var incidentGR = new GlideRecord('incident');
incidentGR.orderBy('sys_created_on');
incidentGR.query();

var previousPriority = null;
var previousNumber = null;

while (incidentGR.next()) {
  var currentPriority = incidentGR.getValue('priority');
  var currentNumber = incidentGR.getValue('number');

  if (previousPriority !== null) {
    gs.info('Current Incident Number: ' + currentNumber + ', Priority: ' + currentPriority);
    gs.info('Previous Incident Number: ' + previousNumber + ', Priority: ' + previousPriority);
    // Comparison logic here, e.g.,
    if (currentPriority < previousPriority) {
      gs.info('Priority decreased from ' + previousPriority + ' to ' + currentPriority + ' for incident ' + currentNumber);
    }
  }

  previousPriority = currentPriority;
  previousNumber = currentNumber;
}

• Explanation: In this revised approach, instead of assigning the entire incidentGR object to previousIncident, we are using getValue('priority') and getValue('number') to retrieve the priority and number of the current record and storing these values in previousPriority and previousNumber respectively, after processing the current record. In the next iteration, currentPriority and currentNumber will hold the values of the subsequent record, allowing for an accurate comparison.

  
  

Practical Applications

This technique is invaluable in various ServiceNow scenarios, such as:

• Inventory Management: Tracking consumption rates by comparing inventory levels at different points in time.

• Change Management: Identifying changes in configuration items by comparing their attributes across audit history records.

• Problem Management: Analyzing trends in incident data by comparing attributes of consecutively created incidents.

• Workflow Logic: Implementing conditional logic in workflows based on the values of the previous record processed.

Why the Initial Approach Fails

As mentioned earlier, the initial attempt to assign previousIncident = currentIncident; fails because currentIncident is simply a reference to the same GlideRecord object that is being moved to the next record with each call to incidentGR.next(). By the time the next iteration begins, both previousIncident and the current state of incidentGR point to the same, newer record.

Conclusion

When working with sequential data in ServiceNow GlideRecord queries, remember that GlideRecord objects are references. To accurately compare the "previous" and "current" records, you must explicitly capture and store the values of the specific fields you need to compare using the getValue() method. This ensures that you are working with independent copies of the data, allowing you to perform meaningful sequential analysis and implement robust logic in your ServiceNow scripts. By understanding this fundamental concept, you can avoid common pitfalls and effectively leverage the power of GlideRecord for your data analysis needs.