The sys_id of a specific user's sys_user record is not the same between Production and sub-Production after clone - Support and Troubleshooting

The sys_id of a specific user's sys_user record is not the same between Production and sub-Production after clone Issue  Symptoms After cloning, some sys_user record's sys_ids are different between Dev and Production. Due to that, some group memberships are having issues. Release London Patch 4, Hot Fix 2 Cause The user has a Data Preserver for the sys_user table on their sub-Production (Dev) instance. This will prohibit a clone from Production down to this sub-Production environment from syncing the sys_ids in question.

Resolution In this case, a sys_user record for one specific user was provided on each instance mentioned, both Production and sub-Production.

On Production, Bucky Barnes' sys_user record has a creation date of 2/23/2016. In the sub-Production instance, his sys_user record has a creation date of 10/15/2015.

The reason these are different, and the reason these have not been "corrected" or "synced" via a clone from Production down to Dev is that the user has Data Preservers set up on their Dev instance.

What this does, as covered in documentation ( ref: Data preservation on cloning target instances ), is protect data on the target instance from being overwritten (When cloning, the "Source" is Production and the "Target" is Dev).

This is why the values are not synced, hence the issue with groups between the two instances.

To resolve this, the user can remove the Data Preserver in their sub-Production instance on sys_user to effectively "sync" the sys_ids during their next clone.

As a convenience, simply append the following to the affected instance to see any Data Preserver(s) on or related to sys_user:

/clone_data_preserver_list.do?sysparm_query=tableLIKEsys_user