The sys_id of the records are not matching between source and target environments post clone

[Dinesh_RS]

Hello Everyone!

The sys_id of the records is not matching between source and target

I would like to know if the sys id of the records in source and target would be same if we clone the instance.

Note : We have not defined a table under "Exclude Table" and "Preserve Data"

Clone results based on Exclusion and Preserver configuration - Support and Troubleshooting (servicen...

[HIROSHI SATOH]

※If you know the tables, you can work around this by migrating only the target tables using XML.

＜Q&A about clones＞

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1080537

Potential Causes and Verification Points

1. Clone Settings Issues:

   • Clone Profile Settings: Verify if any tables or data are excluded in the clone profile settings. Specifically, review the settings under "Exclude Tables" and "Preserve Data" to see how they might affect the cloning process.

2. Data Integrity Issues:

   • Data Consistency: If data integrity was not maintained during the cloning process, sys_id discrepancies might occur. Check the logs from the cloning process to see if there are any error messages or warnings.

3. Impact of Existing Data:

   • State of the Target Instance: If the target instance had pre-existing data, there might be conflicts during the cloning process, leading to different sys_ids. Verify the state of the target instance before the clone.

4. Custom Scripts or Business Rules:

   • Script Execution: If custom scripts or business rules were executed during the clone, they might change sys_ids. Check whether the option to disable business rules during the clone is correctly set and if any specific scripts were running.

Verification Steps

1. Check Clone Settings:

   • Review the clone profile settings to confirm that there are no exclusions or data preservation settings that could affect the process.

2. Review Clone Logs:

   • Examine the logs from the cloning process to identify any errors or warnings that may indicate why sys_ids are different.

3. Verify State of the Target Instance:

   • Ensure there was no pre-existing data in the target instance, especially in the custom tables, before the clone process.

4. Inspect Custom Scripts or Business Rules:

   • Check for any custom scripts or business rules that might have run during the clone, specifically those that might alter sys_ids.

[Amit Pandey]

Hi @Dinesh_RS 

Would encourage you to raise a hi ticket. I believe the table was not cloned properly. Let ServiceNow team help on this.

Regards,

Amit

[Mark Roethof]

Hi there,

It can happen that for some artifacts sys_ids mismatch. For example when installing a store application, performing a patch or upgrade. Tables are for example are literally newly created while installing a plugin, while artifacts like business rules or script includes will have the same sys_ids.

A different sys_id for a table doesn't have to be an issue, or in most cases is simply not an issue. And a clone will just cleanup this difference. I have never seen a company add clone excluders/preservers for a Table (or actually the sys_db_object record). Ofcourse your situation might differ, though usually you don't do any scripting or flow based on the sys_id of a table. Usually you do that based on the name of the table which is no issue.

Ofcourse I don't know your instance so can't tell with 100% guarantee, though setting up a excluder and preserver for the table as you are mentioning sounds really weird and unnecessary.