---
sourceDocument: Xanadu ServiceNow AI Platform Administration
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/xanadu/platform-administration

 Release :

    - xanadu

ft:locale :

    - en-US

ft:publication_title :

    - Xanadu ServiceNow AI Platform Administration

ft:clusterId :

    - platadm

bundleId :

    - platadm

workflow :

    - Platform


---

# Push notification retention

# Push notification retention {#ariaid-title1}

* Release version: Xanadu
* 
* Updated August 1, 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read

You can archive and eventually destroy push notifications that you no longer need or if
your Push Notification table is excessively
large.

Push notification retention is available starting with the Jakarta release.

## Push notification archive and destruction plugins

The push notification archiving and destruction feature uses the Data Archiving and Push
Retention plugins. The Data Archiving plugin must be active to archive and destroy push
notification records. The Push Retention plugin provides a set of rules that specify when the
system archives and destroys push notification records.

In new instances, the Push Retention plugin and associated archive and destroy rules are
active by default. On upgraded instances, you must manually activate both the plugin and the
archive and destroy rules. Be sure to review and approve the archive and destroy rules before
activating them.

If your instance already has a process for managing push notification records, you do not need
to activate the Push Retention plugin. If you want to replace your current process with Push
Retention, be sure to deactivate the current process before activating the archive and destroy
rules.

## Archiving and destroying push notification records


Archiving means moving records from the Push
Notification \[sys_push_notification\] table to the Push Notification Archive \[ar_sys_push
notification\] table when they exceed the archive rule time limit.
Destroying means deleting records in the Push Notification Archive table when
they exceed the destroy rule time limit.

## Default archive and destroy rules

Push retention provides the following push archive rules:

* Push Notification - Over a year old: archives push notification records that were created more than 365 days prior to the current date.
* Push Notification Archive - Over a year old:destroys push notification records that have been archived for more than 365 days prior to the current date.
{#push-notification-retention__ul_pkg_tqt_5x}  
With these default settings, your messages are kept on the instance for a total of two years: one year in the Push Notification table, and one year in the Push Notification Archive table. At the end of the period, the system deletes the expired notification records from the Push Notification Archive table.  
Note:  
By default these rules are active on new instances and inactive on upgrades. The system runs archive and destroy rules when you activate them.

## Compatibility with other record management implementations

If you are already using another method for managing push notification records, such as table cleaners, you do not have to use the Push Retention feature. To prevent unexpected record deletion, avoid using multiple push notification management processes on the same instance at the same time.  
Note:  
For assistance replacing your existing record management implementation with push notification retention, contact your professional services or sales representative.
* **[Activate the Push Retention plugin](https://servicenow-prod.fluidtopics.net/j1wUpJL0GLv2lmSC2h33bQ)**   
  The Push Retention plugin (com.glide.push_retention) provides the retention policy for push notifications, so that you can specify when the system archives and destroys push notification records.
* **[Archive push notifications manually](https://servicenow-prod.fluidtopics.net/XAh~lCiVjgP95EPHYDbU0Q)**   
  You can manually archive push notifications on demand instead of waiting for the instance to archive them based on a scheduled job.

**Related tasks**   

* [Activate push notifications](https://servicenow-prod.fluidtopics.net/fPbiPvA0orzM4ShlqpnZ4Q "Several plugins must be activated to use push notifications. If you have the Mobile UI (com.glide.ui.m) plugin active, push notification plugins are automatically activated.")
* [Requeue failed push notification messages](https://servicenow-prod.fluidtopics.net/HqXm~JQdMLM3xF9kUlO~mA "Push notification delivery might fail for various reasons. You can view which messages failed and requeue them to be sent out if necessary.")  
**Related reference**   

* [Push notification system](https://servicenow-prod.fluidtopics.net/S9n3HtMVWBiPvojotHPVug "The push notification system involves several key elements that manage the delivery of push messages and push notification responses.")
* [Installed with push notifications](https://servicenow-prod.fluidtopics.net/xOQTbjgGRkYMyxuBIr85pQ#r_InstalledWithPushNotifications "Several types of components are installed with the push notifications plugins.")
* [Push notification properties](https://servicenow-prod.fluidtopics.net/he7WcMntJ0AxCKKG~Ginbw "Push notifications provides several properties to customize the setup.")
* [Push notification setup with the ServiceNow mobile app](https://servicenow-prod.fluidtopics.net/MwVGMVn3PYkoYPnHAv14Tg "The ServiceNow mobile application automatically enables push notifications and configures mobile devices for push notifications when users initially log in to the instance.")
* [Push notification setup with a custom push application for ServiceNow mobile apps](https://servicenow-prod.fluidtopics.net/jhLL1OpxEfmGgs~1XgE2yg "If you are using your own custom mobile or push application, you must configure your app for use and set up the push contents.")