Overview

An access control is a security rule defined to restrict the permissions of a user from viewing and interacting with data. Most security settings are implemented using access controls.

They execute when attempting to access any ServiceNow table and may be set at the row or column level.

These rules restrict ServiceNow-specific and CRUD operations.

In addition to restricting CRUD operations, access control rules can restrict ServiceNow-specific operations on tables and fields.

ServiceNow operation examples include:

Execute: user cannot execute scripts on a record or UI page.

edit_ci_relations: user cannot define relationships between Configuration Item [cmdb_ci] tables.

save_as_template: controls the field that should be saved when a template is created.

report_on: user cannot create reports on the object.

personalize_choices: user cannot right-click a choice list field and select Configure Choices.

ACL evaluation process

Process order for record ACL rules

A user must pass both field and table ACL rules in order to access a record object.

• If a user fails a field ACL rule but passes a table ACL rule, the user is denied access to the field described by the field ACL rule.
• If a user fails a table ACL rule, the user is denied access to all fields in the table even if the user previously passed a field ACL rule.

Access control definition: rule types

How to Determine If a User Has Permissions to Create, Read, and Write on an Extended Table

Description

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.

 

Note:

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 indicate the rule failed. Therefore, the user does not have the permissions to create, write, or delete records in the selected table.