sys_id mismatch for sys_user_roleSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This is expected behavior, as sys_user_role records are not sys_id‑driven.As outlined in the Coalesce Strategies section of the ServiceNow documentation, records on these tables are coalesced based on meaningful field values (such as names) rather than sys_id. Coalescing can be illustrated using an employee record example. If integrations relied solely on sys_id, recurring data loads could fail to recognise the same employee across systems. To prevent this, specific fields—often a combination of string values—are treated as the primary identifier instead of sys_id. This approach simplifies data handling and is widely used across the base Glide platform. By treating these records as data rather than configuration, both internal and external components can reliably identify, update, and reuse the information, regardless of instance‑specific sys_id values. Compare local update sets (Section Coalesce strategies) This behavior is also documented in the Update Sets guidance.As noted in the Get Started with Update Sets documentation, some base system records are created during instance provisioning and may not match across independently created instances. This can lead to inconsistencies when moving update sets between environments. Get started with update sets (Point 3)**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. One of the customer’s instances should be designated as the baseline instance, which is typically Production. Full clones should then be performed from Production to all lower environments to maintain consistency of records, including role sys_ids where alignment is required. Once all environments are cloned from the Production instance, the relevant sys_id values will be synchronized across those instances. It is important to note that PDI instances or instances belonging to other organizations cannot be compared with customer instances, as sys_id values are influenced by the original provisioning version and the sequence in which plugins were installed. KB2715225 - Differences in the list of active applications or plugins between instances following an upgrade? For additional guidance, refer to the following KB, which outlines best practices for onboarding and go‑live scenarios. While it addresses a different context, it reinforces the recommendation to clone all sub‑production environments from a baseline instance: KB0965738 - On-Boarding/Go Live Best practice ( Tech Support Perspective) This coalescing behavior must be considered when working with custom configurations. Issues can occur when an update set or configuration XML captures a specific sys_id from one instance and is then committed to another instance that was not cloned from Production. During plugin, custom application, or Store app installations, problems may arise when roles are not correctly associated with records due to a sys_id mismatch between the incoming role references and the roles present on the target instance. In most cases, this occurs when the role field (for example, table_name.roles) is configured as a List field. List fields store role values as a comma‑separated list of sys_ids (for example, sys_id1, sys_id2, sys_id3). If the instance cannot resolve these sys_ids to existing roles, the roles will not be assigned. Recommended Remediation Work with the application owner to change the role field type from List to User Roles (user_roles). This field type is specifically designed for role tracking and stores values as role names (for example, rolename1, rolename2, rolename3).Using User Roles allows the base platform coalescing logic to align roles correctly, ensuring consistent behavior regardless of instance‑specific sys_id differences. 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)