There are several thousand tables in ServiceNow, and the records in these tables are linked together as if in a net. Removing a node (a specific record) from this net has consequences for the surrounding nodes, which reference the record to be deleted. In the best case, the loose ends are either neatly obliterated (the reference is removed in the source record) or the referencing record is also deleted. In the worst case, the loose ends remain in the system and then represent so-called "broken references".

Even more "broken references" can occur for indirect references. These can be for example references in a condition builder or the records from the journal table, because there the Sys IDs to the referencing record are stored in a pure string field.

Either way, deleting records can lead to data corruption or incorrect as well as unexpected behavior, but ServiceNow does not provide any feature to get an overview of all referencing records and their type of relations. You only get a warning when deleting a record if there are referencing records that will also be deleted automatically (so called cascading deletion):

But neither you can open the list of these records nor you can be sure, that really all referencing records are captured. Therefore, visualizing as many references as possible would be an extremely helpful feature.

For this reason, I built a feature "Generate References Report" which can be found in the context menu of a record's form view.

It kicks in the report generation on server-side and visualizes the progress with a well-known progress bar.

After finishing, the report can be opened by clicking on the respective button below the progress bar. In the last column of that report, you can find the number of records for the given table. By clicking on that number, you are redirected to the corresponding filtered list view.

As you can see in the screenshot, even a simple Change Request can have many referencing records.

Notes

It was surprisingly difficult to implement a solution. The challenge arose from the concept of table inheritance, whereby both the parent tables and all child tables must be taken into account.

Another difficulty is the fact that a table can have several columns that (redundantly) reference the same record. This is especially the case with the child tables of the task table. Originally, there was only the field "Parent" defined on the task table. Later, however, many child tables (for example the "Change Task" table in the above screenshot) introduced an additional and individually named field such as "change_request" or "wm_order".

The values in "type" column represent the different reference types we have in ServiceNow. It would go beyond the scope of this article to go into detail about all of them. However, I will write a larger article on the topic of "references" later and link it here then.

The most important information is provided in the column "Delete Cascade Rule" as it represents the respected behavior when deleting the referenced record. Also that topic is too large to explain it in detail and I will cover this in the mentioned article.

And the real value of this report results in the last column, which not only outputs the number of referencing records, but also offers this number as a link to get to the list view of all these references.

Implemented Solution

The solution consists of 3 artifacts, and an Update Set containing them can be downloaded from the related Share project.

UI Action "Generate References Report"

It configures and opens an invisible and undocumented UI Page "hierarchical_progress_viewer". But there are many code examples in the OOTB scripts available and also the Community article How to make a custom progress bar - a guide to GlideScriptedHierarchicalWorker was a great help. Apart from some additional client-side code for providing a cancellation option, the JSON-based result data is consumed to build up the report in another modal.

Script Include ReferencingRecordsReportAjax

That Script Include acts as a mediator between client side and server side. Its method "start" (don't change the name!) is invoked by the previously mentioned UI page "hierarchical_progress_viewer" to instantiate a new GlideScriptedHierarchicalWorker() object and return its ID back to the client. With that ID, the client script then can periodically pull the progress from the server. This periodic communication is completely covered by the UI page "hierarchical_progress_viewer", so you don't need to care about it.

A second method "cancel" takes the cancellation request from the client and leverages the respective API to stop the progress worker.

Script Include ReferencingRecordsReportImpl

That Script Includes hold all the business logic for generating the report data. It is implemented it in a way which allows leveraging it independently if you want to test it in a different context:

var objGenerator = new ReferencingRecordsReportImpl();
var objReport    = objGenerator.createReport('change_request', '8ecd7552db252200a6a2b31be0b8f581');

gs.info(JSON.stringify(objReport, null, '    '));