Orphaned Attachments

What it does

Reads every attachment on your instance and tells you which ones belong to records that have been deleted.

Then it tells you, in one number, how much space you could reclaim today.

It cannot delete anything. There is no delete method and nothing delete-shaped reachable from the page. It finds the files; removing them is your decision, made with the platform's own tools, where it is logged as yours.

The problem it solves

Delete a record in ServiceNow and its attachments do not always go with it. They stay in the attachment table, filed against a sys_id that no longer resolves. Nothing on the instance points at them, no list will show them, no cleanup job considers them, and they keep occupying space for years.

On a stock instance we found 57 of them. On one that has been lived in for five years, with records deleted and imports rolled back, it is worse — and nobody has ever been able to see it.

What else it looks for

The table it belongs to no longer exists - The whole table has gone. No query will ever reach this file and no cleanup will ever consider it. A second copy of the same file - The same content attached twice to the same record. One of the two can go without losing anything.

Plus the twenty largest files, listed rather than judged. Large is not the same as wrong, but if you are looking for space, that is where it is.

Why you can trust the numbers

This is a tool that tells you which files might be deletable, so being wrong about one is not a cosmetic problem. Every check was measured against a real instance before it was written, and the headline one changed completely.

The obvious orphan check reports 2,497 orphans out of 3,006 attachments. The real number is 57.

The reason is that table_name on an attachment is not always a table name. Many attachments are system-managed and carry a ZZ_YY prefix — ZZ_YYdb_image alone accounts for over a thousand — and those are not tables you can query. "No such table, therefore orphaned" condemns every one of them. This resolves the real table first, which is the entire difference between a useful report and one that would have you deleting a thousand perfectly good files.

Duplicates went the same way: 205 down to 19. The same file attached to two different records is entirely normal — a shared logo, a standard form, the same evidence filed against two incidents. Only a second copy on one record is waste.

What it will not pretend to know

About a quarter of attachments on a typical instance carry no content hash. Those cannot be compared to anything, so they are excluded from the duplicate check and the report tells you how many were set aside. Quietly assuming they are unique would make the number look better and mean less.

A sentence, not a score

The report ends with a sentence saying how many attachments it read, how many belong to things that are gone, and roughly how many megabytes that is.

Deliberately not a number out of a hundred. A score invites a threshold, a threshold invites somebody deciding that seven is acceptable, and after that nobody reads the detail again.

What installing it costs you

Nothing to configure, nothing to connect, nothing to trust with a credential.

It stores nothing. There is no table in this application. Every answer is computed when you press the button and thrown away when you close the page.

It never writes, and it never deletes. That is not a promise in a document — it is two tests in the shipped ATF suite: no script in the application can modify the attachment table, and no client-callable method has a delete-shaped name.

It stops reading at 4000 attachments and tells you when it did.

One role, x_nf_attach.user. It shows you what you could already read by querying the attachment table yourself. It just asks the question you would have had to ask 3,000 times.

Why it is free

It is the fastest way to show you how we build: one screen, one role, no tables, and a documented reason for every decision in it. If it earns your trust, our paid work is built the same way.