Cloning instances with AES
Summarize
Summary of Cloning instances with AES
This guide explains how ServiceNow customers can clone instances while protecting data, tables, and templates created in App Engine Studio (AES). It focuses on ensuring data integrity and collaboration continuity when copying from production to non-production environments using System Clone.
Show less
Key Requirements and Considerations
- All AES plugins must be installed on every instance involved in the cloning process.
- Data preservers must be configured on target instances to protect Automated Test Framework (ATF) and Instance Scan properties, preventing accidental test runs on production.
- The App Engine Management Center (AEMC) plugin is required on all instances if collecting development and deployment data.
- Cloning from production to non-production can overwrite data; therefore, a clear cloning strategy for collaboration and data preservation is essential.
Data Preservation and Clone Exclusions
To ensure critical collaboration data is retained correctly during cloning, specific tables have data preservation enabled, focusing on global scope:
- Collaboration Descriptor tables: sysappcollabdescriptor, sysappcollabpermissionm2m
- Collaboration Users and Groups tables: sysappcollabuser, sysappcollabgroup
Clone exclusions prevent production data from overwriting development instances in these same tables.
If AES is the only application using the Credentials table, data preservers should be created for credential-related tables (Credential Alias, Basic Auth, Discovery credentials) to avoid data loss.
User Role Reassignment and Post-Clone Actions
- Users in the AES Users group, AES User Limited group, and those with snappengstudio.user roles in non-production must have roles reassigned post-clone.
- An automatic post-clone script, ReSync Collaborations Permissions, synchronizes collaborators on applications present in both production and development, enabling developers to resume work immediately.
- The collaboration plugin must be enabled on cloned instances.
- Additional UI actions allow manual resynchronization of collaboration permissions and cleanup of unreferenced collaboration records after cloning completes.
Preserving Application Templates
Custom AES templates are at risk of being overwritten during cloning because template applications are treated like standard custom apps. To protect these templates, admins must create clone or data preservers on non-production instances following standard procedures.
Additional Tables with Data Preservation
Other tables related to pipeline instances and deployment requests also have data preservation enabled to ensure correct cloning behavior:
- Pipeline Instance
- Request Authorization Key
- Deployment Request
- Deployment Environment Request
Further Resources
ServiceNow offers extensive documentation and resources to support cloning with AES, including knowledge articles, FAQs, whitepapers, and training materials available through ServiceNow University. These resources provide deeper guidance on System Clone, data preservation techniques, and best practices.
Learn how to protect the data, tables, and templates you've created in App Engine Studio when using System Clone to copy instances from production to non-production.
Preserving data and tables when cloning
- Verify that all of your AES plugins are installed across all instances.
- If you're cloning a production instance, verify that you've set up a data preserver on the target instances to preserve the Automated Test Framework (ATF) and Instance Scan properties. For more information about data preservers, see Create a clone preserver and Create a data preserver (legacy).Important:By default, the ATF system property is disabled to prevent you from accidentally running these tests on a production system. Running ATF on a production instance is neither recommended nor supported due to the potential for data corruption or outages.
- If you're collecting development and deployment data, the App Engine Management Center (AEMC) plugin must be installed on all instances.
- The following tables have data preservation to ensure that the tables are correctly cloned between instances:Note:For the following tables, preservation is for global scope only.
- Collaboration Descriptor tables:
- App Collaboration Descriptors (sys_appcollab_descriptor)
- App Collaboration Descriptor Permissions (sys_appcollab_permission_m2m)
- Collaboration Users and Groups tables:
- App Collaboration Users (sys_appcollab_user)
- App Collaboration Groups (sys_appcollab_group)
- Collaboration Descriptor tables:
- The following tables have clone exclusions:
- Collaboration Descriptor tables:
- App Collaboration Descriptors (sys_appcollab_descriptor)
- App Collaboration Descriptor Permissions (sys_appcollab_permission_m2m)
- Collaboration Users and Groups tables:
- App Collaboration Users (sys_appcollab_user)
- App Collaboration Groups (sys_appcollab_group)
- Collaboration Descriptor tables:
- If AES is the only application using the Credentials table, consider creating data preservers for Credential Alias, Basic Auth, and Discovery credentials. Otherwise, you must ensure that these tables aren't overwritten when the production instance is cloned to non-production instances.
- The following users must be reassigned their roles after cloning:
- Users in the AES Users group
- Users in the AES User Limited group
- Users who have the sn_app_eng_studio.user role in non-production instances
- After cloning, a ReSync Collaborations Permissions post-clone clean-up script runs automatically, so any applications that were the same on production and development
instances are automatically have collaborators synced. Developers can resume development on them immediately. Note:The cloned instance must have the collaboration plugin enabled.
- If some applications were backed up prior to cloning and retrieved after cloning, you can use the Resync collaboration permissions related link on the sys_app record to reassign users and groups to their appropriate delegated development permissions.
- If a collaboration descriptor is no longer associated with a user or group after cloning (in the event that development apps were wiped out during cloning as they were not in the source instance), select the Clean up records with empty references related link to remove the unreferenced user or group from the collaboration table. You should run this UI action after the cloning is done and all preserved applications have been retrieved (with Resync collaboration permissions already run on them).
- Pipeline Instance
- Request Authorization Key
- Deployment Request
- Deployment Environment Request
Preserving app templates when cloning
Admins must protect custom templates from being overwritten during the cloning process. Without protection, templates created in AES (both from existing applications and from scratch) are in danger of disappearing during a clone.
When you create a template in AES, a scoped app is automatically generated on the Custom Applications [sys_app.list] table in your instance. Though they have different contents, template applications and standard custom applications are treated similarly on the ServiceNow AI Platform. So, preserving app templates during a system clone works the same way as preserving an application.
To protect app templates on your non-production instances, follow the process in Create a clone preserver or Create a data preserver (legacy).
More information on cloning and data preservation
- For more information on using the System Clone tool, see Instance Clone.
- For more information on data preservation, see Create a clone preserver.
- For more details on cloning instances with AES, see the App Engine Studio System Administrator Guide on ServiceNow University.
| Learn more about cloning instances with AES | Additional ServiceNow resources |
|---|---|
| ServiceNow provides several additional resources on cloning instances with App Engine Studio. | |
Note: You must log in to ServiceNow University to access this resource. |