ACL Denies Access After Upgrade<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } Symptoms: After a platform upgrade, users suddenly lose access to a specific table that was previously fully accessible. No ACL (Access Control List) restrictions existed on the table before the upgrade, and users had full read or write permissions. However, immediately following the upgrade, access is denied to all users. Cause: During the upgrade, a new ACL record was inserted into the instance. This ACL includes an "Allow If" condition that inadvertently restricts access for most users. Because this is a new ACL and not a modification of an existing one, the upgrade engine applies the change silently without generating any skipped records. The record appears to have "created" and "updated" fields which times are before the upgrade time, making it harder to detect when manually reviewing the ACL records. Furthermore, this change is not logged in the sys_upgrade_history table, which is typically used to track modified or skipped records during upgrades or update sets. The only way to trace this change is by inspecting the sys_upgrade_history_log table. Workaround: To identify whether such an ACL was introduced during the upgrade, follow the steps below: 1. Navigate to: System Diagnostics > Upgrade History Log(or directly open the sys_upgrade_history_log table) 2. Apply the following filters: File name starts with sys_security_aclTarget name is <Table Name> (replace with your actual table name) 3. Group the results by: File name 4. Review the entries to identify any ACL records that were inserted as part of the upgrade. Once identified, review the condition and logic in the newly introduced ACL. You can then choose to: - Add the roles required by the ACL records to some user groups, and then add users into the groups.- Add additional ACLs to grant access as appropriate.- Consider the customizing to disactive the ACL records. Recommendation: As a best practice, always perform a full ACL audit post-upgrade on sensitive tables and include a check of the sys_upgrade_history_log to catch newly inserted records that may affect security or access.