Broken References

What it does

A reference field holds the id of a row in another table. The caller on an incident. The owner of a configuration item. The manager on a user record.

Delete that row - offboard the person, retire the CI, clean up after an import • and the pointer stays behind, pointing at nothing.

This finds those.

Why nobody notices

Nothing errors.

The form shows an empty field with no explanation. The notification addressed to that person goes nowhere and reports itself as sent. The report that groups by that field quietly drops the record from the total, so the number is wrong and looks fine.

ServiceNow ships no screen for this. There is no flag on the record and no "broken references" module. Finding them means walking the dictionary for reference fields and checking every pointer's target yourself.

What the measurement said

On the development instance this was built against, a default sweep across ten tables found 54 of 3,258 pointers checked pointing at a record that no longer exists - on a near-vanilla instance with almost no history.

That count grows with the age of an instance rather than shrinking. Every person offboarded and every CI retired leaves more behind.

It samples, and it says so

This is the part worth understanding before you read a result.

Checking every pointer on a real instance would be the outage it was opened to prevent. So it reads a bounded number of rows per table - 150 by default, newest first, up to 500 - stops after 6,000 pointers, and tells you exactly how many it checked.

Which means a result of none is a clean sample, not a clean instance, and every screen says that rather than letting you read silence as safety. There is a screen listing which tables were in the sweep, which are present on your instance, and which it could not read.

It also reads inherited reference fields. Most of what incident and change_request point at is defined on sys_task, and a version that read only a table's own dictionary rows would check almost nothing and hand back an empty answer that looked clean.

What it will not do

It cannot repair anything. There is no write path in this application at all - not disabled, not behind a flag.

That is deliberate rather than unfinished. A pointer that goes nowhere is the last remaining evidence of what the record used to be attached to. Clearing it looks like tidying up and is actually destroying the only clue: the incident still knows it had a caller, and that id is the thread back to who it was.

It will not judge a table it cannot read. Where the target table is closed to it, those pointers are left alone rather than counted as broken. Inventing findings out of a permission boundary would be worse than missing them.

It stores nothing. No tables ship with it, so there is nothing at rest and an uninstall cannot leave residue.

Where it stops

150 rows per table by default, 500 at most, 6,000 pointers before it stops - and it says when it stopped. Narrow a sweep to a single table to look further into that table.