- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2023 11:07 AM
Hi All,
We are preparing for an upgrade and I have to clone Prod to Test. Unfortunately, the initial implementation is not documented well. Too many unknowns. What steps should I take to prevent integrations from breaking?
I am trying to figure out what we need to do to prevent unexpected workflows from triggering in our Test environment. I am setting up a new profile. Are there recommended tables that I should preserve or exclude when cloning?
There is demo data in our test environment. Should I clean the demo data out first via Now Support portal?
I have been reading through the clone documentation--lots to review.
Any tips or suggestions?
Best,
Kathy
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2023 12:51 PM
Hi @kathymorris,
Here are some steps that I suggest you take to prevent integrations from breaking and unexpected workflows from triggering in your test environment:
Before cloning, review your integrations and identify which ones are bidirectional or outbound from your test environment. You may want to disable or redirect these integrations to avoid sending data to external systems or production instances. You can use the Integration Hub > Connections module to manage your integrations and their credentia...
Before cloning, review your workflows and identify which ones are triggered by events, timers, or scheduled jobs. You may want to disable or modify these workflows to avoid running them automatically or repeatedly in your test environment. You can use the Workflow > Workflow Editor module to manage your workflows and their trigger conditi...
Before cloning, review your clone profile and specify which tables and data you want to exclude or preserve during the cloning process. You can use the System Clone > Clone Definition module to create or edit your clone profile and add ... Some recommended tables that you may want to exclude or preserve are:
- Exclude Tables: These are tables that contain data that are specific to your test environment and should not be overwritten by the production data. Some examples are sys_email, ecc_queue, sys_trigger, syslog, sys_audit, sys_update_set, etc
- Data Preserver: These are tables that contain data that are common to both environments and should be merged during the cloning process. Some examples are sys_user, sys_user_group, sys_user_role, cmdb_ci, cmdb_rel_ci, etc
After cloning, review your integrations and workflows again and enable or restore them as needed. You may also want to test them in your test environment and verify that they are working as expected.
After cloning, review your demo data and decide if you want to keep them or remove them from your test environment. You can use the System Definition > Scripts - Background module to run a script that can load or delete demo data for a specific application. For example, you can use the following command to load Vulnerability Response demo data: GlidePlugin...
Hope this helps.
Kind Regards,
Swarnadeep Nandy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2023 12:40 PM
Hello Kathy,
there are OOB Data preservers to deal with "integrations" not breaking on the clone target instance. I suspect you can across that reading Clone documentation. Also, clones can be rolled back if needed if performed withing a few days.
I doubt any workflows will trigger due to the clone, they generally run when data changes. I've never heard of any related problems from a clone.
The data on the target instance will be replaced with that from the source instance. If there are not Data Preservers defined for what ever tables you are concerned with. The OOB Data Preservers take care to preserve instance specific data (configuration).
The clone feature is important so development can occur, and be tested, on sub-prod instances and have confidence that when moved to Production, there will be no problems. So you want those instances as close to your production instance as possible. And all customers clone periodically. And reported problems are rare.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-16-2023 12:51 PM
Hi @kathymorris,
Here are some steps that I suggest you take to prevent integrations from breaking and unexpected workflows from triggering in your test environment:
Before cloning, review your integrations and identify which ones are bidirectional or outbound from your test environment. You may want to disable or redirect these integrations to avoid sending data to external systems or production instances. You can use the Integration Hub > Connections module to manage your integrations and their credentia...
Before cloning, review your workflows and identify which ones are triggered by events, timers, or scheduled jobs. You may want to disable or modify these workflows to avoid running them automatically or repeatedly in your test environment. You can use the Workflow > Workflow Editor module to manage your workflows and their trigger conditi...
Before cloning, review your clone profile and specify which tables and data you want to exclude or preserve during the cloning process. You can use the System Clone > Clone Definition module to create or edit your clone profile and add ... Some recommended tables that you may want to exclude or preserve are:
- Exclude Tables: These are tables that contain data that are specific to your test environment and should not be overwritten by the production data. Some examples are sys_email, ecc_queue, sys_trigger, syslog, sys_audit, sys_update_set, etc
- Data Preserver: These are tables that contain data that are common to both environments and should be merged during the cloning process. Some examples are sys_user, sys_user_group, sys_user_role, cmdb_ci, cmdb_rel_ci, etc
After cloning, review your integrations and workflows again and enable or restore them as needed. You may also want to test them in your test environment and verify that they are working as expected.
After cloning, review your demo data and decide if you want to keep them or remove them from your test environment. You can use the System Definition > Scripts - Background module to run a script that can load or delete demo data for a specific application. For example, you can use the following command to load Vulnerability Response demo data: GlidePlugin...
Hope this helps.
Kind Regards,
Swarnadeep Nandy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-17-2023 08:17 PM
Hi Swarnadeep,
Thanks for your reply. The URL links above in your message, I cannot navigate to. I tried different browsers. Can you paste the URLs please?
Thanks,
Kathy