sys_id mismatch for sys_user_roleSummary1. This is expected behaviour and sys_user_role records are not sys_id driven.Please check the section Coalesce Strategies in the below documentation. The records on the mentioned tables are coalesced on the field names and not on sys_id.KB1258524 - Compare local update sets2. We have also covered the same in this documentation.KB1258512 - Get started with update sets**Note from doc** Some base system records are created on an instance after provisioning and do not match between different instances, leading to problems with update sets. The best way to avoid this issue is to:Provision production and non-production instances.Clone the production instance onto the non-production instance.3. One of the customer's instances should have been chosen as the "baseline" instance (usually it's Prod) and full clones should have been done from Prod to all the lower instances to keep all the sys_id of roles in sync (if that has to be).4. Once all instances of a customer are cloned from the PROD instance the sys_id should be in sync. 5. We cannot compare a PDI instance/Instance for another organization with an instance as the sys_id depends on which is the first version this instance was provisioned and the order of plugins that got installed. 6. Attached is a KB that outlines the best practices for Go live which is a different context and it is mentioned there to clone all sub-prods from a baseline version.KB0965738 - On-Boarding/Go Live Best practice ( Tech Support Perspective) 7. This Coalesce strategy should be imposed with a custom configuration. This can be an issue where there is an update set/configuration XML captured with a specific sys_id of a record on another instance which is getting committed on an instance that is not a cloned instance of the PROD While installing a plugin/custom application, there are issues observed when the roles are not linked to the records because there is a sys_id mismatch of the incoming roles with the roles on the instance. If this issue is observed and in most cases, the table_name.roles field will be having a field type as "List". If this is a "List" the data is stored as sys_id1, sys_id2, sys_id3. So if this comes as a Custom Configuration/Plugin Installation/Custom App installation/Store App installation the roles will not be assigned to that record if there is a sys_id mismatch ( if the instance cannot find the role with the sys_id) Remediation of this will be to work with the app owner to change the Field Type of the role field name to User Roles [user_roles] as this is an explicit field type to track roles and the values will be passed as rolename1, rolename2, rolename3 where Coalesce strategies will be imposed by base code and the roles will be aligned irrespective of the sys_id of the role on that instance Screenshot where roles are passed as sys_id ( role Field type is a list). Screenshot where roles are passed as role names ( role Field type is user_roles)