Non-Matching sys_ids for ACLs Generated from Dictionary Attributes (Bootstrap vs. Update XML)Issue When comparing Access Control List (ACL) records for the same table/field across different instances (or against a baseline/parent instance), some ACLs show different sys_ids even though their function, table, field, and roles are identical. This is most commonly noticed on ACLs tied to fields like work_notes on the task table, and can cause confusion during audits, upgrade comparisons, or when troubleshooting update set collisions, since the ACL does not coalesce as expected. The same non-matching sys_id behavior can also occur when a customer creates a custom ACL directly on an instance. Symptoms Pick a field-level ACL that is known to be generated from a dictionary attribute rather than shipped as its own XML record, for example the work_notes field on task, defined in task.xml with read_roles="itil" and write_roles="itil,task_editor".Compare the sys_security_acl record for that field across two different instances (or against the OOB baseline).Note that the table, field, operation, and roles all match, but the sys_id of the ACL record differs between instances.Check for a corresponding sys_security_acl_<sysid>.xml file in the shipped source; none exists, since this ACL was never shipped as a discrete update record.Separately, have a customer create a custom ACL directly on the table/field in question (rather than importing it via update set or app install).Compare that custom ACL's sys_id against the same custom ACL created independently on another instance; note the sys_ids also do not match, for the same underlying reason. Release All Cause There are several scenarios in which two functionally identical ACLs can end up with different sys_ids: Bootstrap-generated: The dictionary entry for a field carries role-restriction attributes (read_roles, write_roles, create_roles, etc.). During instance bootstrap, plugin activation, or upgrade, the platform reads these attributes and generates the corresponding sys_security_acl record on the fly. Because this record is synthesized at runtime rather than shipped as a fixed-sys_id XML file, each instance mints its own sys_id independently, so the same effective ACL can end up with different sys_ids on different instances.Custom ACL creation: When a customer creates a new ACL directly on an instance (through the UI, rather than importing it via an update set or plugin/app package), the platform generates a new sys_id locally at the moment of creation. If the same ACL is recreated independently on a different instance (rather than migrated via update set), it will receive its own locally generated sys_id, so the two instances end up with functionally identical ACLs that do not share a sys_id.Explicitly defined: The ACL is shipped as a discrete sys_security_acl_<sysid>.xml record (via plugin or app install), with the sys_id embedded directly in the file. Since the sys_id is part of the shipped artifact, it stays identical across every instance that installs it. Per ServiceNow documentation on update set collisions, sys_security_acl (via sys_security_table) is not a table that coalesces on update sets, so this sys_id divergence in either scenario above is expected, by-design behavior rather than a defect. Cloning can align sys_ids between two instances at a point in time (since it copies the already-generated record), but this is not a durable fix, as a later bootstrap/upgrade pass, or a manually recreated custom ACL, can reintroduce the mismatch. Resolution There is no platform-level change needed, since this is expected behavior for both bootstrap-generated ACLs and independently created custom ACLs. Per KB0749174 (Customization considerations for Access Controls (ACLs)), if the customer needs to loosen security or grant additional access, the recommended approach is: Do not modify the OOB bootstrap-generated ACL directly.Create a new ACL granting the desired access (role, condition, or script) for the same table/field.Since only one passing ACL is required at the table level and one at the field level, the new ACL alone is sufficient to grant the desired access, and it will not be affected by future upgrades, as only OOB objects are subject to upgrade changes.If the custom ACL needs to be consistent across multiple instances (for example, dev, test, and production), migrate it via update set rather than recreating it manually on each instance, since migrating preserves the sys_id and avoids the mismatch described above.Use clone functionality to maintain the same sys_id between instances