How to resolve denied access when ACL blocks table access after upgrade<!-- /*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: ; } } Issue Learn how to resolve a loss of table access that can sometimes occur after a platform upgrade. This is not an expected result of an upgrade but can occur when an access control list (ACL) introduced by the upgrade denies access that previously worked. Most upgrades do not remove existing table access. This article is for use after an upgrade; refer to it only if you find that access has unexpectedly changed. If you have not upgraded yet, no advance action is needed. Test your upgrade in a non-production environment before you upgrade your production environment. Testing first also gives you a non-upgraded environment to compare against if you later need to diagnose an access change (see Resolution). Cause Platform upgrades can introduce new baseline ACL records, often as part of security updates. This is normal and usually intended. In rare cases, a newly introduced ACL can unexpectedly restrict access that previously worked, which is the situation this article addresses. When that happens, the upgrade has inserted one or more new ACL records that include an Allow If condition restricting access for affected users. Because these ACLs are new, not modifications of existing ones, the upgrade engine applies them silently and does not generate skipped records. Their Created and Updated field times can also be earlier than the upgrade time, which makes them harder to spot when you review ACLs manually. This change is not recorded in the System Upgrades [sys_upgrade_history] table, which usually tracks records modified or skipped during upgrades or update sets. You can trace it only in the Upgrade Details [sys_upgrade_history_log] table. Resolution To catch this kind of change before it reaches production, test upgrades in a non-production environment first. While testing, you can review ACLs on sensitive tables and compare the sys_upgrade_history_log entries against an environment that has not yet been upgraded, so you can identify and address any access changes ahead of your production upgrade. To check whether an ACL was introduced during the upgrade and restore access: 1. Go 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 <your table name> 3. Group the results by File name. 4. Identify which ACL records were inserted during the upgrade. To tell which records are new, compare this list against the same list from an environment that has not yet been upgraded, for example, a non-production instance. ACL records that appear in the upgraded environment but not in the non-upgraded one were introduced by the upgrade. Note: This comparison works only when you have an environment that has not yet been upgraded. Testing the upgrade in a non-production environment first gives you that comparison point. 5. Review the condition and logic in the newly introduced ACL. Then choose one of the following options to restore appropriate access: - Add the roles required by the ACL to user groups, and then add users to those groups. - Add additional ACLs to grant access as appropriate. - Deactivate the ACL records.