--- sourceDocument: Australia ServiceNow AI Platform Administration sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/platform-administration Release : - australia ft:locale : - en-US ft:publication_title : - Australia ServiceNow AI Platform Administration ft:clusterId : - platadm bundleId : - platadm workflow : - Platform --- # Configuration tab # Configuration {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 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 Configuration The Configuration menu in the Clone Admin Console centralizes all clone-related settings, including exclusions, preservers, cleanup scripts, clone profiles, and clone instances. This consolidation replaces the deprecated Definitions tab, streamlining clone management. Before starting, note that some default exclusions, preservers, and scripts cannot be removed and that external email addresses can be added for clone notifications. Show full answer Show less ## Exclusions Exclusions define tables that are not copied during cloning. Excluding a parent table truncates both it and its child tables, though only the parent appears in the exclusions list. Default exclusions cover logging, auditing, notifications, workflow contexts, and license usage tables. Additional tables can be excluded as needed to control what data is omitted from clones. ## Preservers Preservers protect data on the target instance from being overwritten during cloning. Unlike exclusions, preservers require child tables to be individually added unless using RaptorDB instances (from which child tables are automatically preserved). This feature helps maintain critical target instance data during the clone process. ## Cleanup Scripts Cleanup scripts automate post-clone tasks and run in a defined order (lower order number means higher priority). Multiple scripts can run in parallel by assigning the same order number. Examples include detecting bad MID Server credentials, resetting scheduled jobs, migrating or disabling email accounts, enabling plugins, and rebuilding text indexes. Error handling in scripts is crucial to ensure subsequent scripts execute properly. Cleanup scripts must be updated on the source instance before the clone's Restore phase. ## Clone Profiles Clone profiles are reusable templates for clone settings, including exclusions, preservers, and cleanup scripts, ensuring consistency across cloning operations. The default System Profile is immutable, but custom profiles can be created, edited, and include all existing custom exclusions and preservers. Profiles simplify managing diverse cloning scenarios. ## Clone Instances and Multi-Instance View The Clone Instances page lists registered source and target instances by URL, allowing easy selection for cloning. Non-production instances can be added to this list. The Multi-Instance View consolidates clone activity across linked instances for better visibility and management. ## Understanding Exclusions and Preservers Combinations * **Preserving and excluding a table:** Keeps target instance records unchanged. * **Not preserving and excluding a table:** Removes source data and clears target records, leaving the table empty but usable. * **Preserving and not excluding a table:** Keeps target data intact while copying source data over. * **Not preserving and not excluding a table:** Source data replaces target data completely. ## Important Considerations Cloning replaces target instance data with source data, so any in-progress work on the target, such as update sets or scoped apps unique to the target, will be overwritten. Export ongoing update sets before cloning and re-import them afterward. Custom applications not present on the source must be reinstalled post-clone. For detailed guidance on managing development and deployment with cloning, consult the Leveraging System Clones for Seamless Development and Deployment Whitepaper. Use the Configuration menu to access all clone-related settings, including exclusions, preservers, cleanup scripts, clone profiles, and clone instances. In the Clone Admin Console, all clone-related settings are consolidated under a single Configuration menu. Note: The Definitions tab has been deprecated and consolidated into the Configuration tab. If you are upgrading from an earlier version, use the Configuration menu instead. Before you begin * You can add external email addresses to receive clone notifications. * Some default items can't be removed from the exclusions, preservers, or scripts list. {#clone-configurations-tab__ul_af2_kd1_lgc} ## Overview page {#clone-configurations-tab__section_fdp_tvr_sgc} The Overview page displays a summary of all the configuration options in your instance. ## Exclusions {#clone-configurations-tab__section_exclusions} The Exclusions page lists the tables that aren't copied during an instance clone. When excluding a table, the clone automation truncates the entire table including its child tables. The clone process excludes (or removes) data from both the parent and the child tables. The child tables, however, aren't individually added to the list of excluded tables. Only the parent table is listed. To view child tables of a table, you can go to the following link and input their table: \[instance\].service-now.com/now/nav/ui/classic/params/target/generic_hierarchy_erd.do. By default, the system excludes tables for logging, auditing, notifications, workflow contexts, and license usage. To configure additional exclusions, see [Exclude a table from cloning](https://servicenow-prod.fluidtopics.net/rD_esQb~PN~S4Xnsm252pA "Exclude a table to create an empty but usable table on the target instance."). For information on guidelines when adding exclusions see [General guidelines for excluding a table from cloning](https://servicenow-prod.fluidtopics.net/G~CxO3o2NislSSnRwRQCTA "A reference topic that includes general guidelines to exclude a table from cloning."). ## Preservers {#clone-configurations-tab__section_preservers} The Preservers page displays a list of available data preservers, which are defined on the source instance. Preservers protect data on the target instance from being overwritten. Preservers work differently compared to exclusions. When preserving a table, the clone automation doesn't automatically preserve the child tables. Therefore, the child tables must be individually added to the preserver list. To create a preserver see [Create a clone preserver](https://servicenow-prod.fluidtopics.net/Q4vcasg1jYdJivj~VRpJhw "Create clone preservers to protect specific data on the target instance from being overwritten during a clone operation. Preservers allow you to retain existing target data while cloning source data for other tables."). Note: Starting with RaptorDB, when you preserve a table, the clone automatically preserves the hierarchy and descendant tables. If you previously added child tables to preservers, they process normally. This automatic preservation applies only to RaptorDB instances. ## Cleanup Scripts {#clone-configurations-tab__section_cleanup_scripts} The Cleanup Scripts page displays a list of all of your available scripts. Cleanup scripts automate post-clone tasks. Set an order number on each script, to set the order that the active scripts run, with lower numbers having a higher priority. To run some scripts in parallel, you can assign the same order to them. All cleanup scripts run in the global scope irrespective of the scope in which you have configured the cleanup script. {#clone-configurations-tab__table_cleanup_scripts_examples__entry__2} | Script | Description | |-|-| | Bad MID Server credentials after clone | Runs a script include called BadMIDCredentialAfterClone on a cloned instance to detect [bad MID Server user credentials](https://www.servicenow.com/docs/access?context=mid-post-clone-issue-resolution&version=australia&pubname=australia-servicenow-platform&ft:locale=en-US). This script include creates scheduled jobs that log MID Servers in the Down state to the MID Server Issue \[ecc_agent_issue\] table after an instance clone. | | Clear scheduled job node association | Resets any scheduled jobs that were active on the source instance to the Ready state. This script also clears the value of the System ID and Claimed by fields on all scheduled jobs. | | Configure Email Accounts | Migrates email accounts that existed on the source instance to the target instance if they aren't enabled there. This script also migrates the email properties to the target instance. | | Disable emails | Disables email on the target instance. A default data preserver maintains other email settings from the target instance. | | Install deactivated plugin | Enables the Domain Separation plugin for instances that use this feature. | | Regenerate all text indexes | Rebuilds text indexes on the target instance after a clone. Text indexes aren't cloned from the source to the target instance. | [Table 1. Post-clone cleanup scripts examples] {#clone-configurations-tab__table_cleanup_scripts_examples} Note: Verify that any custom scripts have error-handling logic. By default, if one script encounters an error, the rest of the ordered scripts don't execute. Starting with the Australia Patch 5 release, you can view a link to cleanup script status. Any changes to cleanup scripts, which are defined on the source, must happen before the Restore phase of a clone to be processed within that clone request. To create a cleanup script see . ## Clone Profiles {#clone-configurations-tab__section_ipw_xvr_sgc} Clone Profiles display all available profiles. Clone profiles are reusable templates for clone settings and can be saved and reused to achieve consistent outcomes with each of your clones. To learn more about Clone Profiles, see [Create a custom clone profile](https://servicenow-prod.fluidtopics.net/rnQ1YeOjlgHOauiy23AyuQ "Clone profiles act as reusable clone templates to establish consistent clone outcomes. Clone profiles enable you to set up exclusions, preservers, and cleanup scripts for specific clone scenarios."). The profile System Profile is available by default and can't be modified. Custom profiles use the default Exclusions, Preservers, and Scripts from the System Profile. When creating a custom profile, all existing custom exclusions and preservers are automatically added. You can create as many custom clone profiles as you'd like and edit them as needed. To change the definitions of a clone profile, such as exclusions, preservers, or cleanup scripts, select the number under the definition and select the Edit button on the page. ## Clone Instances {#clone-configurations-tab__section_qk1_xvr_sgc} The Clone Instances page displays registered instances and their URLs. You can use instances added to this list as a clone source or clone target for your clones. To add your non-production instance to your clone instances list, select New. ## Multi-Instance View {#clone-configurations-tab__section_multi_instance_view} The Multi-Instance View provides consolidated clone activity across linked instances. ## Clarifying exclusions and preservers combinations {#clone-configurations-tab__section_ahk_kxg_bgc} Clone exclusions and preservers are both useful for managing your data. The graphics help to identify the expected outcome of the following combinations of preservers and exclusion combinations. For more information, see the [February 2025 Platform Fundamentals Academy session on Clone Admin Console](https://www.servicenow.com/community/servicenow-ai-platform-blog/platform-fundamentals-academy-february-20th-2025-clone-admin/ba-p/3170929). * Scenario 1: Preserving and excluding a table. You want the records on your target instance to remain the same. * Scenario 2: Not preserving and excluding a table. You want records from your source instance not to be copied over and records on your target instance to be removed: The table is empty but usable after the clone. * Scenario 3: Preserving and not excluding a table. You want records on your target Instance to remain the same and records for your source instance to be copied over. * Scenario 4: Not preserving and not excluding a table. You want records from your source instance to replace records on your target instance. {#clone-configurations-tab__ul_rs3_wxc_cgc} Important: During a clone, data from the source instances replaces data from the target instance. Therefore, any in-progress development work on the target instance is overwritten. For example: Work-in-progress update sets, scoped apps that only exist on the target instance but not on the source instance. If you have in-progress update sets, you must export them before the clone and re-import them after the clone is finished. Custom applications that aren't yet deployed to the source instance must be reinstalled after the clone is completed. To learn more about clone and app development tips, see the [Leveraging System Clones for Seamless Development and Deployment Whitepaper](https://learning.servicenow.com/nowcreate/en?id=nc_asset&asset_id=ce3c254697cc82d06eedb30e6253af3b&nc_source=copy_asset_link).