ACL evaluation failed: access denied for table incident

User lacks the required role specified in the ACL rule for the target table. The user's role assignment may have been removed or never granted. (high likelihood)

ACL condition script contains errors or evaluates to false, blocking access even when the user has correct roles. JavaScript errors in condition scripts prevent proper evaluation. (high likelihood)

No matching ACL rule exists for the specific operation (read, write, create, delete) on the table. ACL rules may be missing or incorrectly scoped. (medium likelihood)

Service account or system user performing background operations lacks necessary roles. Integration users or scheduled job accounts may have insufficient permissions. (medium likelihood)

Table-level security constraints or field-level ACLs are conflicting with table ACLs. Multiple security layers may be blocking access unexpectedly. (low likelihood)

Step 1: Navigate to System Diagnostics > Log > Application Log and search for the exact error message to identify the specific user, table, and operation involved.

Step 2: Go to System Security > Access Control (ACL) and filter by the table name (e.g., incident) to review all existing ACL rules for the target table.

Step 3: Check if ACL rules exist for the specific operation (read, write, create, delete) by examining the Operation field in each ACL record.

Step 4: Verify the user's role assignments by navigating to User Administration > Users, finding the affected user, and checking their Roles related list.

Step 5: Test ACL condition scripts by opening the ACL record and clicking the Test button, or check for JavaScript errors in the Condition field.

Step 6: If no appropriate ACL exists, create a new ACL rule with correct table, operation, and role requirements, or modify existing rules to grant proper access.

Step 7: For service accounts, ensure the integration user has necessary roles by checking System Web Services > REST API Explorer or the specific integration user record.

Step 8: Test the fix by impersonating the affected user or re-running the operation that triggered the original error to confirm access is granted.