---
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


---

# Preserving data from target instances during clones

# Preserving data from target instances during clones {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 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 Preserving data from target instances during clones

In ServiceNow clones,data preserversprotect specific data on the target instance from being overwritten by source data.
This is crucial when certain data, such as MID Server configurations, must remain intact on the target instance.
Data preservers are defined on thesource instanceto ensure target data protection during cloning.
Note that unpublished application content requires manual preservation outside of data preservers.
Show full answer Show less  

## Key Features

* **Data Preservers Functionality:** They reapply preserved target data after exclusions during cloning, protecting system settings and themes like authentication settings, bookmarks, recent selections, and user preferences.
* **Preservation Scope:** Preserving a parent table also preserves its child tables, except for clones involving MariaDB instances where child tables must be preserved manually.
* **Restrictions:** Data preservers do not support preserving data from database views and are not suitable for transferring large data sets (e.g., users, groups, roles). For large data sets, exporting and importing records post-clone is recommended.
* **Multi-SSO Integration:** When Multiple Provider Single Sign-On (Multi-SSO) is activated, ServiceNow automatically creates data preservers for relevant tables (e.g., certificates, system properties related to authentication, digest properties, identity providers, and SAML2 properties).
* **Care with Multi-SSO Preservers:** Avoid modifying these auto-created preservers. If Multi-SSO is disabled on the target, all related preservers must be removed simultaneously to prevent clone errors.
* **Unpublished Applications:** Data preservers do not preserve unpublished application versions. Developers must decide how to preserve these manually, as cloning copies only the installed version from the source instance. Unpublished or development versions on the target instance will be overwritten or deleted accordingly.

## Practical Implications for ServiceNow Customers

* Always define data preservers on the **source instance** before cloning to protect critical target data.
* Use data preservers primarily for system settings and small data sets; avoid using them for large record sets to prevent performance and consistency issues.
* For Multi-SSO-enabled instances, rely on the system-generated preservers to maintain authentication configurations during cloning.
* Plan for manual handling of unpublished applications to maintain development versions across instances.  
You can use data preservers to protect data on the target instance from being
overwritten. If you have custom applications, you must also manually preserve unpublished
application content.

## Data preservers {#data-preservation__section_bkt_swj_t1b}

Sometimes, it is necessary to preserve some data on an instance targeted for cloning. For example, if the target is a MID Server, you must not overwrite the MID Server \[ecc_agent\] table. Preserved data is reapplied to the target instance after exclusions are completed.  
Warning:  
You must define data preservers on the source instance. Defining them on the target instance does not preserve the data.  
Data preservers typically preserve system settings and themes, such as:

* Instance-specific authentication settings
* Bookmark \[sys_ui_bookmark\]
* Recent Selection \[sys_ui_recent_selection\]
* User Preference \[sys_user_preference\]

{#data-preservation__ul_z14_zps_yfb}  
Note:  
A clone does not support preserving data from a database view.

Preserving a parent table also preserves all of its child tables. For clones between MariaDB instances, child tables aren't automatically preserved and must be manually added to the preserver list.

Don't use data preservers to transfer large sets of data, such as user groups. If you must preserve table data, such as users, groups, and roles, consider exporting the records to a file and importing
them after cloning.

## Data preservers for Multi-SSO {#data-preservation__section_zwz_swj_t1b}

The system automatically creates the necessary data preservers for cloning when you activate Multiple Provider Single Sign-On integration.{#data-preservation__section_zwz_swj_t1b__entry__3}

| Name | Table | Conditions |
|-|-|-|
| Certificate | X.509 Certificates \[sys_certificate\] | None |
| Core Instance Properties | System Property \[sys_properties\] | * \[OR\] \[Name\] \[is one of\] \[glide.authenticate.external, glide.authenticate.external.logout_redirect\] * \[OR\] \[Name\] \[starts with\] \[com.snc.integration.saml_esig\] * \[OR\] \[Name\] \[is one of\] \[glide.smtp.port, glide.smtp.auth, glide.smtp.encryption\] * \[OR\] \[Name\] \[starts with\] \[glide.authenticate.multisso\] * \[OR\] \[Name\] \[is\] \[glide.authenticate.sso.redirect.idp\] {#data-preservation__ul_ix2_p1n_q5} Note: The properties glide.smtp.port, glide.smtp.auth, and glide.smtp.encryption are deprecated. |
| Digest Properties | Digest Properties \[digest_properties\] | None |
| Identity Providers | Identity Providers \[sso_properties\] | None |
| SAML2 Update1 Properties | SAML2 Update1 Properties \[saml2_update1_properties\] | None |
[ ]

Note:  
Although you can modify these data preservers, it is good practice not to. The Digest Properties \[digest_properties\], Identity Providers \[sso_properties\], and SAML2 Update1 Properties \[saml2_update1_properties\] tables are required for multiple source, single sign-on (SSO) to function properly. If multiple source, single sign-on is disabled on the target instance, you can safely remove all three data preservers. Remove them at the same time, as the system terminates the clone with an error message when you attempt to clone with one or two of these tables being preserved.

## Preservation of unpublished applications {#data-preservation__section_ijw_wrn_z1b}

You can't use data preservers to save unpublished applications. Instead, application developers must choose how they want to preserve unpublished applications.

The cloning process does not preserve version differences for applications in development. Instead, the system clone only copies the application version installed on the source instance onto the target instance. If the target
instance had a development version of the same application, the application is editable after the clone, but maintains the version installed on the source instance. If the application was missing from the source instance, the
cloning process deletes the application from the target instance.

