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