Issue
ServiceNow uses access control list (ACL) rules, also called access control rules, to control what data users can access and how they can access it. ACL rules allow users to update records using API protocols such as web services. If a user does not have the necessary permissions to create, read, or write on an extended table, this can pevent the New or Edit buttons from appearing on a related list or unexpected results.
Procedure
To find out if the issue is caused by write or create access, turn on Security debugging for this session. The Debug Security Rules module places a debug icon on each field of a form. Point to the icon to see if there are any debug messages for the associated element. Click the icon to expand details about read and write access. The Debug Security Rules module is very helpful when you are using ACLs to control access to records and fields.
- To create or edit ACL rules, you must elevate privileges to the security_admin role.
- Impersonation can simplify debugging ACL rules. First enable ACL debugging, then impersonate another user to see what ACL rules the user passes and fails.
To verify ACL rules are not preventing the New and Edit button from appearing on a related list:
- Navigate to System Security > Debug Security Rules to enable ACL rule debugging.
- Reproduce the issue as the affected user.
- Scroll down to the bottom of the form to view the ACL rule output messages.
The output message lists the ACL rule name, the permissions required, and the evaluation result (pass or fail).
- Review the Debug Output and search the table name and find the security rule output.
In this example, we are investigating the [task_sla] table, so search for the term "task_sla." We find a number of red text security debug output that indicates the rule failed. Therefore, the user does not have the permissions to create, write, or delete records in the selected table.
