Manage and mass-delete data from a ServiceNow table - Support and Troubleshooting

Manage and mass-delete data from a ServiceNow table Issue .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Explore methods for mass-deleting data from a ServiceNow table, with or without filter conditions. This article covers four approaches ordered from simplest to most advanced: UI actions, clone exclude rules, table cleanup policies, and JavaScript. It also covers planning considerations, maintenance strategies, and the ServiceNow policy on data removal requests.

The best approach depends on your situation. For large quantities of records, clone exclude rules are the fastest option but may not be suitable for all scenarios. If you have a business-critical need to delete multiple millions of records and cannot wait for the time required by other methods, open a case with ServiceNow to consult a Technical Support Engineer.

ServiceNow policy on data removal requests Platform data relationships are complex and extend beyond simple database table management. Enhanced table models, reference fields, business logic, workflows, and customizations make it impossible to remove data from the backend without risk. ServiceNow cannot intervene in data removal unless the presence of those records is causing a business-critical operation to be unusable, has caused or will cause an outage, or those records are the result of a defect or problem.

Disclaimer No portion of this article is intended to be implemented as-is on a live instance without thorough validation and testing. The contents are provided without warranty or assurance of suitability for any given situation. Use of any script or implementation provided in this article is done at your own risk.

Planning Before deleting data in bulk, consider the following:

What cascade deletions will occur? (Child and related records) What references will be broken or cleared? What business rules will be triggered? What workflows will run? What other features could be affected? (Cross-scope privilege generation, and so on) Will the deletion be tracked by update sets? Researching these questions beforehand helps you identify potential side effects and plan for cleanup afterward. For example, you may need a plan for replacing broken references.

Backout planning Backout options for a mass deletion are limited — exporting a large number of records is generally not viable. The Delete Recovery tool is the best option, as it records deletions and allows you to restore them, including restoring broken references. For more information, see the Roll back and delete recovery documentation.

There is no automatic undo option. Use extreme caution when formulating and executing your plan.

Deleting with UI actions Pros Simple Cons Slow; vulnerable to cancellation by UI transaction quota rules; inflexible This is the simplest approach. To delete all records from a table, open the sys_db_object record for that table and select the Delete All Records UI action. By default, UI transactions are limited to approximately 5 minutes. If the deletion exceeds that duration, it is automatically canceled. For tables with a large amount of data, or data that triggers many business rules or cascade deletions, you may need to increase the transaction quota to complete the operation.

You can also filter a table in the list view, select multiple records, and select the Delete UI action. Due to pagination, the number of records you can select and delete at once is limited. For large record volumes, this approach may not be viable.

Deletions using UI actions trigger business rules and workflows and are tracked by update sets. These UI actions use a GlideRecord object and the deleteMultiple() function internally. The performance is comparable to the following script:

var gr = new GlideRecord("table_name"); gr.query(); gr.deleteMultiple(); Deleting with clone exclude rules Pros Very fast Cons Inflexible — truncates the entire table; can leave broken references and orphaned records; requires a clone, not viable for production When a clone excludes a table, that table is truncated. Truncation is faster than deleting records individually, but references to the excluded records on other tables are broken — those fields still contain the sys_id of records that no longer exist, which can cause unintended consequences.

Direct table truncation also risks orphaned data. In table-per-class (TPC) hierarchies, each extended table exists as a separate physical table in the database. These tables are joined to form complete rows. If you truncate one table in the hierarchy, the data is removed from that physical table, but the joined rows on parent and child tables remain. Data corrupted this way is considered orphaned and is no longer accessible through normal platform means. If you are excluding a table in a TPC hierarchy — unlike the Task and CMDB hierarchies — exclude all parent and child tables as well to avoid creating orphaned data.

Deleting with table cleanup policies Pros Runs in the background on a schedule; flexible configuration; does not trigger business rules or workflows (unless the table has the iterativeDelete attribute) Cons Slow; designed for ongoing maintenance, not ideal for one-time deletions Table cleanup policies are a good solution for routinely deleting records that meet simple criteria — for example, closed tasks that have not been updated after a specific amount of time. The table cleaner job runs once per hour.

Unless the table has the iterativeDelete attribute set to true, the underlying code does not use a GlideRecord to perform the deletion. This means business rules and workflows are not triggered, which can significantly improve performance. It also means the deletion is not audited or tracked by update sets. If the iterativeDelete attribute is present and set to true, these engines are triggered.

When implementing a table cleanup policy on a large table, verify that a supporting index exists for the cleanup condition.

The following is an example of a table cleanup policy that deletes incident records in the Closed state that have not been updated in 30 days.

<img style="border: 1px solid black; align: baseline;" title="By deleting with table cleanup policies, you could have outdated and closed incident records deleted on a schedule." src="/sys_attachment.do?sys_id=8599d513472803d4b7832920326d4387" alt="By deleting with table cleanup policies, you could have outdated and closed incident records deleted on a schedule." width="605" height="174" align="baseline" border="1" hspace="" vspace="" /> Deleting with JavaScript Pros Near-limitless flexibility; can bypass business rules, workflows, and other engines; can be run directly or added to a business rule, UI action, or scheduled job; not vulnerable to transaction quota rules when run in the background Cons Slow; risky; requires scripting knowledge Run JavaScript code directly using the Scripts - Background module. This module includes a C ancel after 4 hours checkbox that is selected by default. For bulk deletion scripts, clear this checkbox. Unless you are deleting data from a scoped table, select the global scope in the dropdown.

The following script deletes all records from a specified table without triggering business rules or workflows:

var gr = new GlideRecord("table_name"); gr.query(); gr.setWorkflow(false); // Bypass business rules and workflows gr.deleteMultiple(); To delete only records that match specific conditions, add query filters:

var gr = new GlideRecord("table_name"); gr.addQuery("state", "closed"); gr.addQuery("category", "4ca01be0db31eb009540e15b8a961936"); gr.addNullQuery("user"); gr.query(); gr.setWorkflow(false); // Bypass business rules and workflows gr.deleteMultiple(); Using setWorkflow(false) also suppresses update set tracking. Use this when you do not need business rules or workflows to run and want the data deleted as quickly as possible. Adding logging to your script makes it easier to debug and evaluate results.

You can add a script like this to a scheduled script execution job to run on a schedule, or create custom UI actions on tables where bulk deletion based on specific logic is a common requirement.

Important: Never run an untested script on a live production instance. Test thoroughly on a non-production instance first. Even a small mistake — such as an incorrectly spelled column name — can lead to unintended results. If data is lost during testing, clone over the non-production instance to recover it.

Maintenance and prevention The most effective way to avoid mass deletions is to prevent data from growing to an unmanageable size. Use table cleanup policies as described in this article to remove data on a schedule. You can also create a scheduled script execution job to perform deletion using JavaScript, though table cleanup policies are more performant in most cases.

Keeping your database lean improves performance and usability, making data more accessible and manageable. A consistent strategy for retiring old data — one that satisfies compliance requirements while keeping your database efficient — has a significant positive impact on platform operations.

Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Zurich

Resolution .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } View Links

Related Links .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Roll back and delete recovery Table Cleaner - Vancouver documentation KB0694151 - How to use Table Cleaner to remove unwanted data KB1518213 - Mastering Data Management in ServiceNow: from tracking growth to efficient cleanup