Best approach for bulk deleting unreferenced Software Models with no entitlements?

[pavan Punna]

Hi Team,

We have a requirement to bulk delete around 65k Software Models that appear to be safe cleanup candidates.

The deletion criteria is:

• Software Model has no entitlements
• Software Model has no references in any related/reference table
• Only models created by approved system/service accounts are in scope

Since Software Models can be referenced across multiple tables, we want to avoid direct bulk deletion and use a controlled, auditable approach.

The strategy we are considering is:

1. Identify safe delete candidates once
   Run a read-only script to find Software Models with no entitlements and no references.

2. Store candidates in a staging/control table
   Store Software Model sys_id, display name, created by, created date, validation status, and backup data.

3. Delete from the staging table in controlled batches
   Process only records marked as safe/pending, using a configurable batch size.

4. Track status per record
   Mark each record as Pending, Deleted, Skipped, or Failed.

5. Produce summary reporting
   Report total scanned, safe candidates, deleted count, skipped count, failed count, and reference reasons.

This would make the cleanup resumable and auditable instead of manually running many individual batches.

Has anyone implemented a similar bulk Software Model cleanup?
Is this staging/control-table approach recommended, or is there a better/simple pattern for safely deleting a large volume of unreferenced Software Models?

[vaishali231]

Hey @pavan Punna ,

Your proposed approach is generally the pattern I would recommend for a large-scale Software Model cleanup, especially when the volume is ~65k records and the deletion must be auditable and recoverable.

1. Staging/Control Table is a Good Practice

Rather than deleting directly from the Software Model table, storing validated candidates in a custom staging table provides several benefits:

1. Creates an audit trail of what was evaluated and deleted.
2. Allows re-validation before deletion.
3. Supports restart/resume if a batch fails.
4. Enables reporting and approval workflows if required.
5. Provides a location to store backup metadata.

For large data-cleanup activities, this is typically safer than repeatedly running ad-hoc background scripts.

2. Consider Re-Validation Before Delete

One risk is that references may be created after the initial scan but before the actual deletion batch runs.

To avoid this:

1. Perform the initial discovery and populate the staging table.
2. Re-check references immediately before deleting each Software Model.
3. If a new dependency is found, mark the record as Skipped rather than deleting it.

This helps avoid race-condition scenarios.

3. Batch Processing is Recommended

For 65k records, avoid a single transaction.

Instead:

1. Use Scheduled Script Executions or a custom processor.
2. Process configurable batches (for example, 500–1000 records per run).
3. Commit progress after each batch.
4. Track execution statistics.

This reduces transaction size and minimizes rollback risk.

4. Capture Reference Validation Results

When a record is skipped, it is useful to record:

1. Referencing table.
2. Referencing record sys_id.
3. Validation timestamp.

This makes post-cleanup analysis much easier.

5. Backup Strategy

Before deletion, consider storing:

1. Software Model sys_id.
2. Name.
3. Created by/on.
4. Key field values (JSON snapshot).

Depending on governance requirements, some organizations export candidate records to XML or CSV for retention before deletion.

6. Verify Entitlement Relationships Carefully

In Software Asset Management environments, direct entitlement checks are often not sufficient.

I would recommend validating:

1. Software Entitlements.
2. Software Installations.
3. Software Discovery Models.
4. Software Catalog relationships.
5. Custom application tables.
6. Any dictionary reference fields pointing to the Software Model table.

Many cleanup projects miss indirect references.

7. Alternative Option

If the primary goal is risk reduction rather than immediate removal, some organizations first:

1. Mark records as Retired/Inactive.
2. Monitor for a period.
3. Delete only after validation.

This provides an additional safety window.

Overall, the staging/control-table approach is a robust and commonly used pattern for large-volume cleanup activities. The only enhancement I would strongly recommend is performing a final reference validation immediately before each deletion rather than relying solely on the initial candidate scan.

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb

[vaishali231]

Hey @pavan Punna 

Hope you are doing well.

Did my previous reply answer your question?

If it was helpful, please mark it as correct ✓ and close the thread . This will help other readers find the solution more easily.

Thankyou & Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb