Record not accessible: no read ACL for this record

User role lacks read access to the table or specific fields being queried, with restrictive ACL rules blocking access to the returned record. (high likelihood)

Dynamic ACL conditions based on field values, user properties, or script conditions are evaluating to false for the current user context. (high likelihood)

Record-level ACL restrictions based on assignment, department, or company fields that exclude the current user from viewing the specific record. (medium likelihood)

Script is running in user context instead of system context, inheriting user permissions rather than elevated system permissions. (medium likelihood)

Table extends another table with more restrictive ACL inheritance, causing unexpected permission denials on child table records. (low likelihood)

Step 1: Check System Logs at System Diagnostics > Logs > Application Logs to identify the exact table and record where ACL denial occurred.

Step 2: Navigate to System Security > Access Control (ACL) and search for read ACLs on the affected table to review permission requirements.

Step 3: Use the ACL Debugger by adding gs.getUser().hasRole('admin') checks or enabling debug logging to trace ACL evaluation for the specific record.

Step 4: Verify the current user's roles and ensure they have the required roles specified in the table's read ACLs using User Administration > Users.

Step 5: Test the query using gs.getUser().setQueryRestrictions(false) temporarily in a background script to confirm if ACLs are the root cause.

Step 6: If script needs elevated permissions, modify the business rule or script include to run with elevated privileges or use GlideRecord.setWorkflow(false) where appropriate.

Step 7: Create or modify the appropriate ACL rule to grant necessary read access, or add the user to the required role if the current restrictions are correct.

Step 8: Test the fix by re-running the script or operation with the affected user account to confirm record accessibility.