---
sourceDocument: Brazil ServiceNow AI Platform Administration
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-administration

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil ServiceNow AI Platform Administration

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# Roll back and delete recovery

# Roll back and delete recovery {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Roll back and delete recovery

Roll back and delete recovery features in ServiceNow enable you to reverse certain actions like patch upgrades, plugin activations, background script executions, and recover deleted records along with related changes.
These capabilities help maintain system stability and data integrity during upgrades or unexpected issues.
Show full answer Show less  
Support for these features depends on the database type of your instance:

* MySQL and MariaDB: support both rollback and delete recovery.
* Oracle: supports rollback only.
* SQL Server: does not support rollback or delete recovery.

## Key Modules and Their Functions

* **Deleted Records module:** Recovers records deleted from audited tables, including cascaded deletions if recovered within seven days. Accessible via System Definition \> Deleted Records.
* **Delete Recovery module:** Recovers any deleted record and related changes within seven days of deletion. Accessible via Rollback \& Recovery \> Delete Recovery.
* **Script Execution History module:** Allows rollback of scripts executed through the Scripts - Background module, maintaining a seven-day history. Accessible via Rollback \& Recovery \> Script Execution History.
* **Rollback Contexts module:** Manages rollback contexts which capture all elements needed to undo patch upgrades or plugin activations, including deleted records, script executions, and database actions. Accessible via Rollback \& Recovery \> Rollback Contexts.

## Rollback Contexts Details

Rollback contexts encapsulate the data necessary to revert patch upgrades and plugin activations that support rollback. They are automatically created during patch upgrades, plugin activations, record deletions, and when scripts run with rollback enabled.

Important considerations for rollback contexts:

* They expire and are deleted after 10 days by default; this period can be extended via system properties.
* Rollbacks should be performed on pre-production instances to restore functionality before troubleshooting.
* Rollback does not affect records modified outside the rollback context.
* Certain schema changes (e.g., dropping tables, renaming columns) prevent rollback context creation.
* Before performing a rollback, consult Customer Service and Support since rollback deletes data and can remove evidence needed for debugging.

## How Rollback Affects Support Cases

When a rollback is performed through Now Support, the following updates occur:

* The reported WAR version is set to the rolled-back version.
* The assigned WAR version remains at the version prior to rollback.
* The instance property `glide.war.noupgrade` is set to the pre-rollback version to prevent automatic upgrade scripts.
* The upgrade state changes to Expired, and stored rollback data is purged.

## Practical Usage for ServiceNow Customers

* Use the Rollback Contexts module to revert patch upgrades or plugin activations efficiently.
* Recover deleted records from audited tables using the Deleted Records module within seven days.
* Recover any deleted record and related changes with the Delete Recovery module within seven days.
* Roll back database changes caused by background scripts using the Script Execution History module.
* Configure rollback context expiration according to your operational needs using system properties.  
With rollback contexts, you can roll back certain actions such as a patch upgrade,
plugin activation, and background script executions, and you can recover record deletions and
all related changes.  
The roll back and delete recovery features are available on instances that use MySQL and MariaDB databases. Instances that use Oracle databases only support roll back. Instances that use SQL Server do not support roll back or delete recovery.{#rollback-delete-recovery__table_epn_wsn_ndb__entry__3}

| Database type | Roll back | Delete recovery |
|-|-|-|
| MySQL | yes | yes |
| MariaDB | yes | yes |
| Oracle | yes | no |
[Table 1. Roll back and delete recovery database support]

{#rollback-delete-recovery__table_epn_wsn_ndb}

## Deleted Records module {#rollback-delete-recovery__section_sbd_xvf_3db}

This module works on records in audited tables. Recovery of cascaded deleted records must be
done within seven days of the record deletion. After seven days, only data records and
references on tables that audit deletions can be recovered, which is the same functionality as
prior releases.

To find this module, navigate to System DefinitionDeleted Records.

## Delete Recovery module {#rollback-delete-recovery__section_uy3_yvf_3db}

This module works for any deleted record. This recovery must be done within seven days of the
record deletion.

To find this module, navigate to Rollback \& RecoveryDelete Recovery.

## Script Execution History module {#rollback-delete-recovery__section_vmf_bwf_3db}

This module works on scripts executed using the Scripts - Background
module. This history only includes seven days of script executions.

To find this module, navigate to Rollback \& RecoveryScript Execution History.

## Rollback contexts {#rollback-delete-recovery__section_tv2_kwf_3db}

Rollback contexts contain everything necessary to roll back a software upgrade or plugin
activation. They include deleted records, patch updates, Scripts-Background script
executions, database actions, and plugin activations. A rollback context is created for each
patch upgrade within a family, and each plugin activation, provided that the plugin supports
rollback contexts.

To use rollback contexts, activate the Restore Deleted Records (com.snc.undelete) and Delete Recovery (com.glide.delete_recovery) plugins.

Rollbacks are typically performed on pre-production instances where functionality must be
restored before you can find the root cause of a problem in the upgrade. Rolling back
deletes data, which can often make it hard if not impossible to discover the problem that
made the rollback necessary.  
A rollback context is created when:

* GlideRecord.delete() or GlideRecord.deleteMultiple() delete records.
* There is a patch upgrade.
* You activate a plugin that supports rollback contexts.
* A script executes using the Scripts-Background module, and rollback was enabled by selecting the Record for Rollback? check box.
{#rollback-delete-recovery__ul_nn3_pkd_kdb}

Rollbacks do not impact other database activities. If a database activity modifies a record
that is part of a rollback context, the rollback does not affect that record.

Because rollback contexts contain a significant amount of data, rollback contexts are deleted after 10 days. Therefore, rollbacks must occur within 10 days of the latest upgrade or plugin activation. If you need to retain a
rollback context for more than 10 days, you can do so by adding a system property. See [Rollback context properties](https://www.servicenow.com/docs/Gw4oHNgXbeqjHfXZN29v0Q "Change the default expiration period for different types of rollback context records.").  
Note:  
Do not roll back a rollback context until checking with Customer Service and Support. A roll back deletes data and may remove evidence of the upgrade or activation issue preventing debugging of the problem.

To find this module, navigate to Rollback \& RecoveryRollback Contexts.

If any of the following operations occur during a rollback, a rollback context is not
created:  
* Tables or columns are dropped from the schema.  
  Note:  
  Index drops are okay.
* A table is truncated.
* A table or column is renamed.
* A column is re-parented or promoted.
* A column type changes.
* A column width is decreased.
{#rollback-delete-recovery__ul_gnk_1fr_jdb}  
The rollback process on Now Support does the following:

* Updates the reported WAR to the rolled-back version and the assigned WAR remains set to the version before the rollback.
* Sets the property glide.war.no_upgrade on the instance is set to the version before the rollback.
* Displays the message, "Desired war matches reverted war specified by property \[glide.war.no_upgrade\]. Upgrade script will NOT run".
* Changes the state to Expired and the rollback purges all stored data.
{#rollback-delete-recovery__ul_lmb_ccf_rfb}
* **[Roll back patch upgrades or plugin activations](https://www.servicenow.com/docs/fJgqVVah2M4yqGV2xF4kZA)**   
  Use the Rollback Contexts module to roll back patch upgrades and plugin activations.
* **[Use the Deleted Records module to restore a deleted record](https://www.servicenow.com/docs/1Kz_HHfcADiEZjDHVHrm3A)**   
  You can recover deleted records that are in audited tables.
* **[Use the Delete Recovery module to restore a deleted record](https://www.servicenow.com/docs/pWcRkopNcU7HO~OxeWtmhA)**   
  You can recover a deleted record and all related changes. The recovery must be done within seven days of the record being deleted.
* **[Use the Script Execution History module to roll back a Scripts-Background execution](https://www.servicenow.com/docs/kZF~tWk_D3BbezsKtWiQlw)**   
  You can roll back the database actions of a script executed using the Scripts-Background module.
* **[Rollback context properties](https://www.servicenow.com/docs/Gw4oHNgXbeqjHfXZN29v0Q)**   
  Change the default expiration period for different types of rollback context records.

*[\>]: and then