Clone Wizard - Guide on how to clone your instance<!-- /*NS Branding Styles*/ --> .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: ; } } /* SnowKB Tab System */ .sna-tabs{font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif;font-size:14px;color:#1d1d1d;max-width:1200px;width:100%} .sna-tabs input[type=radio]{display:none} .sna-tab-labels{display:flex;flex-wrap:wrap;gap:2px;margin-bottom:0;padding:0;list-style:none;width:100%} .sna-tab-labels label{flex:1 1 160px;min-width:160px;text-align:center;padding:8px 10px;background:#f0f4f7;border:1px solid #d0dce4;border-bottom:none;border-radius:4px 4px 0 0;cursor:pointer;font-weight:600;font-size:13px;color:#444;transition:background .15s,color .15s;white-space:nowrap;box-sizing:border-box} .sna-tab-labels label:hover{background:#ddeaf2;color:#02506b} .sna-tab-content{display:none;border:1px solid #d0dce4;border-radius:0 4px 4px 4px;padding:24px 28px;background:#fff} #cwiz-tab-1:checked~.sna-tab-labels label[for=cwiz-tab-1], #cwiz-tab-2:checked~.sna-tab-labels label[for=cwiz-tab-2], #cwiz-tab-3:checked~.sna-tab-labels label[for=cwiz-tab-3], #cwiz-tab-4:checked~.sna-tab-labels label[for=cwiz-tab-4], #cwiz-tab-5:checked~.sna-tab-labels label[for=cwiz-tab-5], #cwiz-tab-6:checked~.sna-tab-labels label[for=cwiz-tab-6], #cwiz-tab-7:checked~.sna-tab-labels label[for=cwiz-tab-7]{background:#02506b;color:#fff;border-color:#02506b} #cwiz-tab-1:checked~.sna-tab-content-1, #cwiz-tab-2:checked~.sna-tab-content-2, #cwiz-tab-3:checked~.sna-tab-content-3, #cwiz-tab-4:checked~.sna-tab-content-4, #cwiz-tab-5:checked~.sna-tab-content-5, #cwiz-tab-6:checked~.sna-tab-content-6, #cwiz-tab-7:checked~.sna-tab-content-7{display:block} .sna-tab-content h2{margin:0 0 18px;font-size:18px;font-weight:700;color:#02506b;border-bottom:2px solid #e0eaf0;padding-bottom:10px} .sna-tab-content h3{font-size:15px;font-weight:700;color:#02506b;margin:22px 0 8px} .sna-tab-content p{margin:0 0 12px;line-height:1.6} .sna-callout-blue{background:#e8f4fb;border-left:4px solid #0e7eb5;border-radius:4px;padding:12px 16px;margin:14px 0;line-height:1.6} .sna-callout-orange{background:#fff4e5;border-left:4px solid #e07b00;border-radius:4px;padding:12px 16px;margin:14px 0;line-height:1.6} .sna-steps{margin:14px 0 14px 0;padding:0;counter-reset:sna-step;list-style:none} .sna-steps li{counter-increment:sna-step;display:block;padding-left:42px;position:relative;margin-bottom:12px;line-height:1.6} .sna-steps li::before{content:counter(sna-step);position:absolute;left:0;top:0;width:26px;height:26px;background:#02506b;color:#fff;border-radius:50%;font-size:12px;font-weight:700;text-align:center;line-height:26px} .sna-table{width:100%;border-collapse:collapse;margin:14px 0;font-size:13px} .sna-table th{background:#02506b;color:#fff;padding:9px 12px;text-align:left;font-weight:600} .sna-table td{padding:8px 12px;border-bottom:1px solid #e0eaf0;vertical-align:top} .sna-table tr:nth-child(even) td{background:#f5f9fc} .sna-pre{background:#f4f6f8;border:1px solid #d0dce4;border-radius:4px;padding:14px 16px;margin:12px 0;font-family:"Courier New",Courier,monospace;font-size:12.5px;line-height:1.6;overflow-x:auto;white-space:pre} .dep-diagram{margin:18px 0;font-family:"Courier New",Courier,monospace;font-size:12.5px;background:#f4f6f8;border:1px solid #d0dce4;border-radius:4px;padding:18px 20px;line-height:1.9} .dep-root{font-weight:700;color:#02506b} .dep-child{color:#1d1d1d;padding-left:24px} .dep-note{font-size:11.5px;color:#666;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Helvetica,Arial,sans-serif;margin-top:4px} a{color:#0e7eb5} 🗺️ Before You Clone ⚙️ Setup & Profiles 🛡️ Preservers 🚫 Exclusions 🔗 User Access Tables 🧹 Cleanup Scripts 🎯 Scenarios 🗺️ Before You Clone Complete every item on this checklist before you schedule a clone. Most clone failures and post-clone access issues trace back to a step that was skipped here. New to cloning? Read KB1214608 — Clone Basics first for a foundation, then come back to this guide for the detailed configuration steps. Getting to the Clone Admin Console All clone configuration and scheduling is managed from the Clone Admin Console. Type Clone Admin Console in the application navigator and select Clone Home. From there you'll find three tabs: Home (your clone history and the Request Clone button), Configurations (clone instances and profiles), and Definitions (preservers, exclusions, and cleanup scripts). Pre-clone checklist Confirm you have admin access on both the source instance (where the data is coming from) and the target instance (where the data is going to).Check that neither instance is currently undergoing an upgrade or in a patching window. A clone running against an instance mid-upgrade will fail or produce an inconsistent result.Confirm no other clone is already running to the same target. Only one clone can run to a given target at a time. Check Clone Home → Home and review the My Clones list.Decide on your backup strategy before scheduling. When you submit a Clone Request, the Backup options field lets you choose between Most recent (uses the latest nightly backup — recommended default) or On-demand backup (triggers a fresh backup at clone start time, which delays when the clone begins). Choose On-demand if a significant change has occurred on the instance since the last nightly backup.Consider your in-progress Update Sets on the target. By default, in-progress Update Sets are not preserved. The Clone Request form has a No. of days of In-progress Global Update Sets to be preserved option — if you have active development work on the target you want to keep, set this before submitting. Note this only applies to Global scope Update Sets. After the clone, you'll still need to review and commit the preserved sets manually. See the ⚙️ Setup & Profiles tab for full details on this option.Think about what integration credentials are configured on your target. By default, source credentials will arrive on the target after a clone — see the note below for what this means and your options. Integration credentials and cloning: When you clone, source credentials arrive on the target as part of the clone data. Whether this is what you want depends on your setup. If your target uses the same credentials as production (common in UAT), no action is needed. If your target should use different credentials — for example dev integrations pointing to dev external systems — you have two options: use Preservers to keep the target's existing credential records, or use Exclusions to block source credentials from arriving entirely. See the 🛡️ Preservers and 🚫 Exclusions tabs to understand both approaches and decide what fits your environment. Outbound email: The clone engine automatically disables outbound email on the target instance post-clone. You do not need to configure this manually. If you want the target to send email after the clone — for example if the target is used for email testing — you will need to re-enable it manually once the clone completes. Text index rebuild: After a clone completes, the target rebuilds its text search index. Search results may be incomplete for several hours. This is expected behaviour. See KB1277450 for details. Admin account types — what you need before cloning You need two types of admin account accessible on the target before you clone. If either is missing, you risk being locked out after the clone completes. Account typeWhat it isWhy you need itLocal (basic auth) adminA username and password account that authenticates directly to ServiceNow — no identity provider (IDP) involved.SSO can break after a clone if source and target use different identity providers. A local admin account is your recovery path. Without one, you may have no way to log in.SSO adminYour standard account linked to your company's identity provider (SAML, OAuth, etc.).Used for day-to-day admin work. Verify it works after the clone once you've confirmed SSO config was preserved correctly. Before any clone to a new target: verify a local admin account exists on the target with a known password. Navigate to sys_user.list on the target, find an admin user, and confirm their Authentication Type is set to Local, not SSO. Further reading KB0715621 — Clone FAQs · KB1214608 — Clone Basics · KB1214621 — Clone Tips and Tricks ⚙️ Setup & Profiles This tab covers what you configure on the source instance before scheduling a clone: the Clone Instance record (which identifies the target), the Clone Profile (an optional named set of rules), and the Clone Request form options that control how the clone runs. Part 1 — Clone Instances A clone instance record tells the clone engine how to connect to the target. It stores the target's URL, admin username, and an encrypted admin password. Setting up a clone instance On the source, open the Clone Admin Console and go to Configurations → Clone instances.Click New.Enter the Instance Name — this must exactly match the subdomain of the target (e.g. mycompany-dev for mycompany-dev.service-now.com).Enter the Instance URL in full: https://mycompany-dev.service-now.com.Enter the Admin User — the local admin username on the target instance.Enter the Admin Password for that account. The password is encrypted at rest once saved.Click Save. The Admin User must be a local authentication account on the target — not an SSO account. The clone engine authenticates directly to the target using basic auth. It cannot go through your identity provider. If you enter an SSO-only account, the clone will fail with an "Invalid username or password" error. Create a dedicated local service account on the target for this purpose. Verifying the credentials before you schedule Test the connection before scheduling. Open a browser, navigate to https://<target-instance>.service-now.com/login.do, and sign in with the admin username and password from the clone instance record. If you can log in, the clone engine can too. Machine identity accounts cannot be validated through interactive login. If the Clone Service Account uses Identity Type = Machine and Web Service Access Only, it is intended for clone authentication only. Maintain a separate break-glass local admin account for interactive login validation and post-clone recovery access. Admin password showing as blank? If the admin_password field on the instance record appears empty, it means a password has never been manually set on that record. Open the instance record on the target, enter the password in the Admin Password field, and save. This cannot be resolved automatically — it requires a manual entry. Part 2 — Clone Profiles A clone profile is an optional named configuration that groups a specific set of Preservers, Exclusions, and Cleanup Scripts together. When you select a profile at clone time, the definitions attached to that profile apply in addition to any globally-defined definitions. Profiles are optional. Preservers, Exclusions, and Cleanup Scripts added under Definitions run for every clone on that instance regardless of which profile is selected. A profile lets you layer additional rules on top for a specific clone type — for example a "Production → UAT" profile with different preservation rules to your default dev refresh. See the 🛡️ Preservers, 🚫 Exclusions, and 🧹 Cleanup Scripts tabs for where to add each type. Profiles live on the source instance. When you schedule a clone, the source applies the selected profile. If you're looking for profiles on your target, you won't find them. Creating a clone profile On the source, open the Clone Admin Console and go to Configurations → Clone profiles.Click New and give the profile a descriptive name (e.g. "Production → Dev Refresh").Optionally attach profile-specific Preservers, Exclusions, and Cleanup Scripts via the related lists on the profile record. See the relevant tabs for guidance on each.Save the profile. Part 3 — Clone Request Optional Settings When you click Request Clone, the form includes an Optional Settings section with three tabs: General, Exclusions, and Preservers. Understanding these before you submit helps you avoid surprises. General tab SettingWhat it doesWhat to considerAmount of data copied from the Task tableControls how much historical data is cloned for the Task table and its child tables (Incident, Problem, Change, etc.). Options are Full or Last 90 days.Selecting Last 90 days does not make the clone faster by reducing data volume alone — the clone engine performs a delete operation on records older than 90 days on the target after cloning, which can actually be slower than a full clone for large Task tables. Choose Full unless you have a specific reason to limit historical data.Backup optionsMost recent uses the latest nightly backup (recommended default). On-demand backup triggers a fresh backup at clone start time — the clone begins only after the backup completes, pushing back the start time.Use Most recent in most cases. Use On-demand if a major change or upgrade has occurred on the instance since the last nightly backup and you want that data included.Clone FrequencySets whether the clone repeats on a schedule. Default is None (one-time clone).Use for regular automated refreshes — for example a weekly dev refresh. Ensure your Preservers and Cleanup Scripts are stable before enabling a recurring clone. Exclusions tab (in Optional Settings) The Exclusions tab within Optional Settings shows three built-in toggles that apply to this specific clone request: ToggleWhat it does when enabledDefaultExclude tables specified in Exclusion listApplies all Exclusion records you've defined (globally or on the selected profile) to this clone. Excluded tables will have empty but usable table structures on the target. If enabled, configured Exclusions are applied. If disabled, configured Exclusions are ignored for this clone request. Some exclusions are enforced by the clone engine itself and still apply regardless of this setting. These clone-engine exclusions cannot be overridden.OnExclude audit and log dataPrevents audit and log records from the source from being cloned. The target will have empty audit and log tables. Note: the Activity Stream on records will not match source, as it is generated from the audit table.OnExclude attachment dataPrevents files (images, documents, videos, zip files) from the sys_attachment table from being cloned. System-relevant files such as catalog item images and theming icons are not affected.On Disabling these toggles: Turning off Exclude audit and log data or Exclude attachment data means those records will be cloned from source. This increases clone time and target footprint. For most non-production environments, keeping all three on is the right choice. Disable only if you specifically need that data on the target — for example, keeping attachments for upgrade or deployment testing. Preservers tab (in Optional Settings) SettingWhat it doesWhat to considerPreserve themePreserves the UI theme of the target instance so it is not overwritten by the source theme. On by default.Keep on if your non-production instance uses a different theme to production (common — many teams use a distinct colour scheme to make it visually clear which instance they're on).No. of days of In-progress Global Update Sets to be preservedPreserves in-progress Update Sets in the Global application scope from the selected time window. Default is None (no preservation). Options include day ranges up to the last 90 days.If developers are actively working in Update Sets on the target and you don't want their work wiped, set this before submitting. Important: this only covers Global scope Update Sets — scoped application Update Sets are not preserved by this setting. After the clone you will need to review and commit the preserved sets manually. In-progress Update Sets outside the Global scope are not covered. If your development work is in scoped applications, this setting will not preserve those Update Sets. Export them as XML before the clone runs and import them back after if you need to keep them. 🛡️ Preservers A Preserver tells the clone engine that certain target data should take precedence over incoming source data. When a clone runs, source data arrives on the target normally — but where a preserved target record shares the same sys_id (the unique record ID in ServiceNow) as an incoming source record, the target record wins and overwrites the source version. Source records with no matching sys_id on the target still arrive as normal. Global Preservers vs profile-specific Preservers You have two places to add a Preserver, and the choice controls when it runs: Where you add itWhen it runsHow to get thereDefinitions (global)Runs on every clone from this instance, regardless of which profile is selected.Clone Admin Console → Definitions → Preservers → NewClone profile (scoped)Runs only when that specific profile is selected at clone time.Clone Admin Console → Configurations → Clone profiles → [your profile] → Preservers related list → New Which should you use? If a table should always be preserved regardless of clone type, add it globally under Definitions. If preservation should only apply for a specific clone scenario, attach it to a profile instead. Preservers Are Not a Data Migration Tool Preservers are intended for configuration and access records, not large-scale data migration. Preservers are typically used for: UsersGroupsRolesCredentialsAuthentication configurationEnvironment-specific records Avoid preserving large transactional tables unless there is a specific requirement. task incident problem change_request sc_req_item cmdb_ci User access preservation: recommended and legacy approaches User, role, and group preservation is more nuanced than simply choosing Preserver + Exclusion. The recommended approach for preserving target access is usually to preserve target access records without excluding user-related source tables, provided the source and target share matching sys_id values for the relevant users. ApproachHow it worksBenefitsCautionsRecommended access preservationPreserver onlyAllow source users to clone across, then use Preservers to restore target values for matching records. For example, if a target user is preserved as inactive, the matching source user record is restored as inactive on the target after the clone.Keeps source user records and references available while allowing target-specific access settings to win where sys_id values match. This is useful when you want source records to remain available for testing but target access controls to be retained.Requires matching sys_id values between source and target for the preserved records. If users were created independently and sys_id values differ, duplicates can occur.Legacy / caution approachPreserver + ExclusionAdd the same user-related tables to both Preservers and Exclusions so source user access data is not copied and only preserved target records remain.Useful where the requirement is to prevent source users from arriving on the target at all.Can break references if not applied carefully across the full dependency set. Excluding tables such as sys_user or sys_user_role should be treated with caution. Important: For user access preservation, do not treat Preserver + Exclusion as the default answer. Preserver-only is often safer when source and target user sys_id values match because source references remain available and target access values can still be retained. Use Exclusions only when you intentionally do not want source records for those tables to exist on the target. Documented recommendation: ServiceNow KB1214621 describes a recommended method to preserve access and users in the target without excluding, and notes that excluding sys_user or sys_user_role can cause broken references. See the KB link above for the full ServiceNow guidance. User access tables The user, group, and role tables are closely related. You do not need to preserve all of them — but the ones you do preserve must be handled as a consistent group. See the 🔗 User Access Tables tab for a full explanation of what each table does, how they depend on each other, and a decision guide to help you choose which apply to your environment. SSO tables — preserve if source and target use different IDPs If your target uses a different identity provider to your source (common — production uses a corporate IDP, dev uses a dev IDP), the source's SSO configuration will overwrite the target's after the clone. Users will be redirected to the wrong IDP and cannot log in. Add these to Preservers if source and target use different SSO configurations: TableWhat it containssaml2_update1_propertiesSAML SSO configurationmulti_sso_propertiesMulti-provider SSO configurationoauth_entityOAuth provider definitionssys_auth_profileAuthentication profiles Integration and credential tables By default, source integration credentials arrive on the target as part of the clone. Whether you need to preserve or exclude them depends on your environment: ScenarioWhat happens by defaultWhat to doTarget should use the same credentials as source (e.g. UAT mirroring production integrations)Source credentials arrive and are active on target.No action needed — this is the default behaviour.Target has its own credentials that should survive (e.g. dev integrations pointing to dev external systems)Source credentials arrive and overwrite the target's credentials.Preserve the target's credential tables so they win over source data. See table below.Target should have no live credentials after the clone (e.g. training instance)Source credentials arrive and are active on target.Exclude the credential tables so source credentials don't arrive, or use a Cleanup Script to deactivate them post-clone. What you want to keep on targetTables to preserveTarget's outbound REST/SOAP integrationssys_rest_message, sys_web_service_definitionTarget's connection aliasessys_alias, sys_connectionTarget's Discovery credentialsdiscovery_credentials + all child tables — see warning belowTarget's MID server configurationecc_agent — see KB0716337 for MID server reload steps post-clone Discovery credentials: preserve the parent table AND all child tables together. Preserving only discovery_credentials leaves orphaned parent records that MID servers cannot read — the credential detail records live in the child tables. This is a known platform issue (PRB1305469). Always preserve all of the following as a set: discovery_credentials · ssh_credentials · aws_credentials · snmp_credentials · windows_credentials · jdbc_credentials · azure_credentials · and any custom credential types in your environment. System properties Most system properties should come from source — that's part of what makes the clone useful. However, some are target-specific, particularly properties controlling integration endpoints. You have two options: add sys_properties to Preservers (keeps all target properties), or let source properties arrive and use a Cleanup Script to reset the specific values that should differ. For most environments, Cleanup Scripts give you more precision — see the 🧹 Cleanup Scripts tab. For a complete list of tables that cannot be preserved, see KB0965249 — Unpreservable Tables. 🚫 Exclusions An Exclusion tells the clone engine to block a table's data from arriving on the target from the source at all. The source data for that table is dropped before it reaches the target — whatever is already on the target for that table is completely unaffected. Exclusions vs Preservers: An Exclusion blocks source data from arriving. A Preserver lets source data arrive but gives the target record precedence where sys_ids match. For Pattern 2, you use both together — the Preserver protects target records, and the Exclusion ensures no source data for that table arrives at all. See the 🛡️ Preservers tab for the pattern explanation and 🔗 User Access Tables for which tables to include. Global Exclusions vs profile-specific Exclusions Where you add itWhen it runsHow to get thereDefinitions (global)Runs on every clone from this instance, regardless of profile.Clone Admin Console → Definitions → Exclusions → NewClone profile (scoped)Runs only when that specific profile is selected at clone time.Clone Admin Console → Configurations → Clone profiles → [your profile] → Exclusions related list → New When to use an Exclusion SituationUse an Exclusion when…User accounts and roles (Pattern 2)You're using Pattern 2 to protect user-access tables. Add the same tables to Exclusions so source data is blocked entirely. See 🔗 User Access Tables.Credentials you don't want on targetSource credentials will arrive by default. If you want the target to have no live source credentials after the clone, exclude the credential tables. This is one option — alternatively you can preserve target credentials (to keep target-specific ones) or use Cleanup Scripts to deactivate them post-clone.Large tables not needed on targetYou want to reduce clone time or footprint by dropping a large table entirely (e.g. historical audit logs not needed on dev).Source-specific configurationYou want to prevent a source-specific integration or service configuration from landing on a target with a different setup. Adding an Exclusion Decide whether this Exclusion should apply to all clones (global) or a specific profile only.Navigate to Clone Admin Console → Definitions → Exclusions for global, or the Exclusions related list on the clone profile for scoped.Click New.In the Table field, enter or search for the table name (e.g. sys_user).Optionally add a filter condition if you want to exclude only a subset of records rather than the entire table.Save the record. Repeat for each table in the dependency group — always add all related tables together. See 🔗 User Access Tables. What Exclusions do not cover Exclusions operate at the table level — they block entire tables (or filtered subsets) from arriving, but cannot block individual fields within a record. To reset a specific field value after the clone, use a Cleanup Script instead. See the 🧹 Cleanup Scripts tab. Common Clone Mistakes Do not exclude attachment tables sys_attachment sys_attachment_doc Use Exclude attachment data instead. Do not preserve attachment tables If a preserved record contains attachments, the clone engine automatically preserves those attachments. Do not exclude sys_properties Use targeted Preservers or Cleanup Scripts instead. Do not preserve large transactional tables task incident problem change_request sc_req_item cmdb_ci Use user and role Exclusions with caution Excluding sys_user or sys_user_role can cause broken references. For target user access preservation, consider the preserver-only method first when sys_id values match. Do not mix dependency strategies Keep Pattern 1 and Pattern 2 consistent within dependency groups. Do not rely solely on SSO Always maintain a break-glass local admin account. For a complete list of tables that cannot be excluded or preserved, see KB0965249 — Unpreservable Tables. 🔗 User Access Tables The user, group, and role tables in ServiceNow are not independent — they form a dependency structure. Understanding how they relate lets you make an informed decision about which ones to preserve or exclude for your environment, rather than applying all of them by default. You don't need to preserve all 8 tables. Which tables you need depends on what you want to survive on the target after the clone. Work through the dependency map and decision guide below to identify the right set for your setup. The three dependency groups The tables cluster into three groups. Within each group, the tables depend on each other — if you preserve a root table, you must also preserve its dependent tables or you'll end up with broken references post-clone. GROUP 1 — USERS ├── sys_user The root. Every user account lives here. ├── sys_user_has_role Which roles are directly assigned to each user. Meaningless without sys_user. └── sys_user_grmember Which groups each user belongs to. Meaningless without sys_user. → If you preserve sys_user, you must also preserve sys_user_has_role and sys_user_grmember. GROUP 2 — GROUPS ├── sys_user_group The root. Group definitions live here. ├── sys_user_grmember Which users are members of each group. Shared with Group 1. └── sys_group_has_role Which roles are assigned to each group. Meaningless without sys_user_group. → If you preserve sys_user_group, you must also preserve sys_user_grmember and sys_group_has_role. GROUP 3 — ROLES ├── sys_user_role The root. Role definitions live here. ├── sys_user_has_role User-to-role assignments. Shared with Group 1. ├── sys_group_has_role Group-to-role assignments. Shared with Group 2. └── sys_user_role_contains Role inheritance — which roles include other roles. Meaningless without sys_user_role. → If you preserve sys_user_role, you must also preserve sys_user_role_contains. STANDALONE └── cmn_notif_device Notification preferences per user (email, SMS). No dependencies on other tables in this group. → Preserve independently if you want users to keep their notification preferences post-clone. What each table contains TableWhat it storesWhat happens without preservationGroupsys_userUser account records — username, name, email, department, active status.Source users overwrite target users. Target-specific accounts (local service accounts, test users) are replaced.Userssys_user_has_roleThe assignment records linking a user to a role. Each row = one user has one role.Users exist but have no roles. They can log in but cannot perform any role-restricted actions.Users / Rolessys_user_grmemberThe membership records linking a user to a group. Each row = one user is in one group.Users and groups exist but no user is a member of any group. Assignment rules and approvals that rely on group membership stop working.Users / Groupssys_user_groupGroup definitions — group name, manager, type, email.Source groups overwrite target groups. Target-specific groups (e.g. dev team groups) are replaced.Groupssys_group_has_roleThe assignment records linking a group to a role. Each row = one group has one role.Groups exist but have no roles. Members of those groups lose any permissions granted via group role assignment.Groups / Rolessys_user_roleRole definitions — the named roles that can be assigned to users or groups.Source roles overwrite target roles. Custom target roles are replaced.Rolessys_user_role_containsRole inheritance records — which roles include other roles within them.Role inheritance breaks. A user assigned a parent role may lose permissions that come from its child roles.Rolescmn_notif_deviceNotification device preferences per user — email addresses, SMS numbers, notification schedules.Source notification preferences overwrite target values. Users on target may receive notifications at the wrong address or not at all.Standalone Decision guide — which tables do you need? QuestionIf yes — preserve theseIf no — what happensDoes the target have its own user accounts that must survive the clone? (e.g. local service accounts, test users, training users)sys_user, sys_user_has_role, sys_user_grmemberSource users overwrite target users. Target-specific accounts are replaced.Does the target have its own groups that must survive? (e.g. dev team groups, training groups)sys_user_group, sys_user_grmember, sys_group_has_roleSource groups overwrite target groups. Target-specific groups are replaced.Does the target have custom role definitions that differ from source? (unusual — roles are usually the same across environments)sys_user_role, sys_user_role_containsSource roles overwrite. In most environments this is fine — roles are typically identical across instances.Do users on target have notification preferences (email/SMS) that should not be overwritten?cmn_notif_deviceSource notification preferences overwrite target values. Recommended access preservation approach: If source and target share matching sys_id values, preserving user-related tables without excluding them is often the better choice. Source users still clone across, preserved target values win for matching records, and references to source users are less likely to break. Choosing the right user access approach GoalRecommended approachWhyKeep target-specific user access, but still allow source users and references to existUse Preservers without Exclusions for the required user, role, and group tables.Preserved target records win where sys_id values match, while source user records can still exist on the target for testing and reference integrity.Prevent all source users from arriving on the targetUse Preserver + Exclusion only after validating the full dependency set.This blocks source data for those tables, but can remove source user records that other cloned data references.Keep only selected target users activePreserve sys_user and related access tables, then store target-only access state such as active=false or group membership on the target.Matching source users can still arrive, but preserved target values can keep selected users inactive or restricted after the clone. Do not mix strategies within a dependency group. Whether you use Preserver-only or Preserver + Exclusion, apply the chosen approach consistently across user, group, role, and membership tables. Missing dependency tables can cause users without roles, users without groups, or broken references. sys_id alignment and why it matters for Preserver-only access preservation Every record in ServiceNow has a sys_id — a unique identifier assigned when the record is created. If your source and target instances share a clone history, the same user record will typically have the same sys_id on both. Pattern 1 relies on this: where sys_ids match, the target record wins. Where a source record has no matching sys_id on the target, it still lands as a new record alongside your preserved ones. If you're unsure whether your instances share sys_id history — for example if the target was built independently or restored from a different source — use Pattern 2. Source data is blocked entirely so no merging occurs. 🧹 Cleanup Scripts Cleanup Scripts are GlideRecord scripts that run automatically on the target instance immediately after a clone completes. Use them to surgically reset specific values that should differ between environments — rather than preserving an entire table, a script lets you change just the fields that need to be different. Outbound email is automatically disabled by the clone engine. You do not need a Cleanup Script to disable email — the clone handles this. If you want the target to send outbound email after the clone (for example if the target is used for email testing), you will need to re-enable it manually by setting the glide.email.active system property to true. How Cleanup Scripts Execute Execution model: All Clone Cleanup Scripts execute as a single scheduled job after clone completion. Scripts execute in ascending Order value. OrderExecution Sequence100Runs first200Runs second300Runs third Important: An unhandled error in one Cleanup Script may impact subsequent scripts. Use try/catch wherever practical. A script error does not roll back the clone. The clone completes successfully; only the script fails. Always test your scripts on a non-critical clone first before relying on them in a production-refresh workflow. Global Cleanup Scripts vs profile-specific Cleanup Scripts Where you add itWhen it runsHow to get thereDefinitions (global)Runs after every clone from this instance, regardless of profile.Clone Admin Console → Definitions → Cleanup scripts → NewClone profile (scoped)Runs only when that specific profile is selected at clone time.Clone Admin Console → Configurations → Clone profiles → [your profile] → Cleanup Scripts related list → New Which should you use? Scripts that should always run after any clone on this instance belong in Definitions. Scripts specific to a particular clone scenario (e.g. reset UAT-specific endpoints only for UAT clones) belong on the relevant profile. Common use cases 1 — Reset integration endpoint URLs to non-production Updates a REST message endpoint so the target points to your dev external system instead of production. // Update REST message endpoint to point to dev external system var rm = new GlideRecord('sys_rest_message'); rm.addQuery('name', 'My Integration'); rm.query(); if (rm.next()) { rm.setValue('rest_endpoint', 'https://dev.external-system.com/api'); rm.update(); } 2 — Deactivate scheduled jobs that should only run on production Sets a scheduled job to on-demand only so it doesn't fire automatically on the target. // Deactivate a scheduled job that should only run on production var trigger = new GlideRecord('sys_trigger'); trigger.addQuery('name', 'Nightly Production Job'); trigger.query(); while (trigger.next()) { trigger.setValue('run_type', 'on_demand'); trigger.update(); } Adding a Cleanup Script Decide whether this script should run after every clone (global) or only for a specific profile. Navigate to Clone Admin Console → Definitions → Cleanup scripts for global, or the Cleanup Scripts related list on your clone profile for scoped.Click New.Give the script a descriptive, ASCII-only name (e.g. "Reset integration endpoint"). Avoid emoji or special characters — they cause an XML parsing error that silently prevents the script from running (PRB1901949).Write your script in the Script field. Use GlideRecord queries by name or other stable identifiers — not by sys_id, as sys_ids differ between instances.Set the Order field. Scripts run in ascending order — lower numbers run first.Save the record. Verifying Cleanup Script Execution After clone completion, verify that all Cleanup Scripts executed successfully. Clone Admin Console Clone Home → My Clones → Open Clone Record → Cleanup Scripts Target Instance System Scheduler System Logs Common mistakes MistakeWhat happensFixQuerying by sys_idThe sys_id of a record on source may not match the same record on target. The script finds nothing and silently does nothing.Query by name, number, or another stable business key.Emoji or special characters in the script nameXML parsing error. The script is skipped silently with no visible error in most views (PRB1901949).Use plain ASCII characters only in script names.Referencing records that only exist on sourceThe script runs on the target post-clone. Source-only records aren't there. The query returns no results.Only reference records you know exist on the target — either because they were preserved or arrived from source during the clone. After every clone, verify your scripts ran successfully. In the Clone Admin Console, go to Home → My Clones, open your clone record, and review the Cleanup Scripts tab. Any failed scripts show an error status and can be re-run manually from this view. 🎯 Scenarios These scenarios provide common clone requirements and recommended solutions. They are intended to give a quick answer first, then point to the detailed section if more context is required. Scenario: I Need Target Users and Roles to Survive the Clone Issue My target instance contains local users, service accounts, test users, training users, role assignments, or group memberships that must remain usable after the clone completes. Solution This can be achieved in more than one way. Do not assume Preserver + Exclusion is always the safest option for user-related tables. OptionHow it worksWhen to use itTrade-offRecommended in many casesPreserver-onlyCreate Preservers for user-related tables and allow source users to clone across. Where sys_id values match, the target record values are restored after clone.Use when source and target share matching user sys_id values and you want source user references to remain available.Requires matching sys_id values. If users were created independently on source and target, duplicates can occur.More restrictivePreserver + ExclusionPreserve selected target records and exclude source data for those tables.Use only when you intentionally do not want source records for those tables to exist on the target.Can break references if cloned records point to source users or roles that were excluded. For user access, start with these core tables: sys_user sys_user_has_role sys_user_grmember These preserve user accounts, user role assignments, and user group memberships. Add group or role definition tables only when your target has target-specific groups or roles that must survive. A useful pattern is to preserve target user records after source users come across. For example, if a matching target user is preserved as active=false, the source user record can still exist after the clone but the preserved target value keeps that user inactive. This avoids deleting source user records and helps preserve references. Reference See the User Access Tables tab for the dependency map and the Preservers tab for the recommended-versus-legacy access preservation approaches. Scenario: Source and Target Use Different Identity Providers Issue After cloning, users are redirected to the wrong Identity Provider and cannot authenticate. Solution Preserve the authentication-related tables: saml2_update1_properties multi_sso_properties oauth_entity sys_auth_profile This preserves the target authentication configuration instead of allowing source authentication settings to overwrite it. Always ensure a local break-glass admin account exists before cloning. Reference See the Before You Clone and Preservers tabs. Scenario: My Integrations Are Different on the Target Issue The target instance uses different endpoints, integrations, or external systems from production. Solution Preserve the relevant integration records or reset them after the clone using Cleanup Scripts. Common examples include: sys_rest_message sys_web_service_definition sys_alias sys_connection Cleanup Scripts are often the simplest option when only endpoint values need to change. Reference See the Preservers and Cleanup Scripts tabs. Scenario: I Do Not Want Production Credentials on the Target Issue Production credentials may overwrite credentials currently used by the target environment. Solution Choose one of the following approaches: Option 1 Exclude credential tables entirely. Option 2 Preserve target credential tables. Option 3 Use Cleanup Scripts to disable or replace credentials after the clone. The correct option depends on how the target environment is used. Reference See the Preservers, Exclusions and Cleanup Scripts tabs. Scenario: Developers Are Actively Working on the Target Issue A clone may overwrite development work currently being performed on the target instance. Solution Use Update Set preservation for active Global Update Sets. Review: Global Update Sets Scoped Application Development Source Control ATF Assets The built-in preservation option only covers Global Update Sets. Scoped applications should be exported or managed using Source Control before cloning. Reference See the Setup & Profiles tab. Scenario: Users Cannot Log In After the Clone Issue Authentication worked before the clone but users cannot access the instance afterwards. Solution Review: SSO configuration Authentication tables Identity Provider settings Local admin access This issue is commonly caused by source authentication settings overwriting target authentication settings, or by user access tables being preserved or excluded inconsistently. Maintain a local break-glass admin account to recover access if required. Reference See the Before You Clone, Preservers, and User Access Tables tabs. Scenario: I Need Attachments for Testing Issue The target environment requires production attachments for testing or validation. Solution Do not preserve: sys_attachment sys_attachment_doc Instead, disable: Exclude attachment data during clone scheduling. This allows attachments to be cloned normally. Reference See the Setup & Profiles and Exclusions tabs. Scenario: Discovery Must Continue Working Issue Discovery credentials stop functioning after the clone. Solution Preserve the complete Discovery credential set: discovery_credentials ssh_credentials windows_credentials snmp_credentials aws_credentials azure_credentials jdbc_credentials Include any custom credential tables used in your environment. Preserving only the parent Discovery table creates unusable credential records. Reference See the Preservers tab. Scenario: Training Environment With No Live Integrations Issue The environment requires production data but should not communicate with production systems. Solution A common approach is: Preserve training usersExclude credential tablesDisable integrationsUse Cleanup Scripts to reset environment-specific configuration This provides realistic training data while preventing connections to live external systems. Reference See the Preservers, Exclusions and Cleanup Scripts tabs. Scenario: I Want to Reduce Clone Size and Duration Issue The clone contains data that is not required for the target environment. Solution Review: Exclude audit and log data Exclude attachment data Large table exclusions Only exclude data that is genuinely unnecessary. Be aware that: Last 90 Days Task Data does not always reduce clone duration and may increase runtime due to post-clone deletion processing. Reference See the Setup & Profiles and Exclusions tabs.