If you are looking at this article, you probably are wondering how to fix an access control (ACLs) issue. I hope to help you on this journey!
What is an Access Control (ACL)?
An instance 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 require users to pass a set of requirements in order to gain access to particular data. Each ACL rule specifies:
The object and operation being secured
The permissions required to access the object
An ACL can effect data security:
A field visible/not visable
A field is readonly/not readonly
A record can be deleted/not deleted
A user can/can’t create a record
Etc
How to edit ACLs
You have to elevate your role to security_admin to edit Access controls
How to elevate your role

Make sure you have the security_admin role. If you don’t have it, someone else with the role will have to grant it to you.
In the User Menu > Click Elevate Roles
In the elevate roles dialog, select security_admin and then click the OK button
Aspects of the Access Control Form
Access Control Form
Field | Description |
---|---|
Type | ACLs can run on Client Callable Script Includes, processor, record, REST_endpoints, and ui pages. 99% of the time you are creating "record" ACLs. Sometimes REST_endpoints. I haven't used the other types, but might someday. |
Application | Application containing the ACL. The scoped application that created this ACL |
Operation | The type of operation on the data. Most common options used: create, read, write, delete, and list_edit. |
Active | If the ACL is active or not. This field is helpful if you are debugging ACLs. You can turn ACLs off until you find the one with the issue. |
Admin overrides | Users with the admin role can override this rule. Personally I think this should always be checked, as an admin should be able to do everything. However there are times when you want to to protect the admin from causing unwanton destruction. |
Advanced | Select this check box to display the Script field on the form |
Protection policy | Controls how application files are protected when downloaded or installed. Aggravates developers by making things readonly, and you have to hack the system to get around this roadblock |
Name | Enter the name of the object being secured, either the record name or the table and field names. The more specific the name, the more specific the ACL rule. You can use the wildcard character asterisk (*) in place of a record, table, or field name to select all objects that match a record type, all tables, or all fields. You cannot combine a wildcard character and a text search. For example, inc* is not a valid ACL rule name, but incident.* and *.number are valid ACL rule names. |
Description | description of the object or permissions this ACL rule secures. |
Requires role | Use this list to specify the roles a user must have to access the object. If you list multiple roles, a user with any one of the listed roles can access the object. The Requires role list appears as a related list. |
Condition | Use this condition builder to select the fields and values that must be true for users to access the object. |
Script | Enter a custom script describing the permissions required to access the object. The script can use the values of the current and previous global variables as well as system properties. The script must generate a true or false response in one of two ways: return an answer variable set to a value of true or false evaluate to true or false In either case, users only gain access to the object when the script evaluates to true and the user meets any conditions the ACL rule has. Both the conditions and the script must evaluate to true for a user to access the object. |
Example TABLE-LEVEL ACLs
Table Level ACL with None

Incident Delete ACL
Delete ACL on the incident table level
Admin Overrides is true and Requires role of itil_admin
If the user has the admin or itil_admin role, they get delete access to the incident table
Table Level ACL with * wildcard
Incident Read ACL
Read acl applies to all the fields on the incident table
Makes all the fields are viewable on the incident table
There are other acls in ServiceNow that block read access to individual ServiceNow fields
TaBLE Level ACL with Script
Table-level ACL for read access on the incident table
Admin Overrides is true
There is a script in the ACL that allows the opened by, caller, or users on the watchlist read access to the incident table.
If a user is an admin, opened by, caller or user on the watchlist on the incident, they get read access.
Example Field Level ACLs
Field Level ACL with Required Role
Field-level ACL for write access on the Incident table for the Caller field.
Admin overrides is true
It requires the itil or sn_incident_write role
If a user has the admin, itil, or sn_incident_write role, they receive write access to the Caller field
Field Level ACL with Condition
Field-level ACL for write access on the Incident table for the Resolution code field.
Admin overrides is true
It has a condition that incident state is not closed
If the incident state is not closed, they receive write access to the Resolution code field
Access Control processing
We just look at individual ACLs and how they work. However it is many individual ACLs working together to form the data security for ServiceNow. They also process within themselves in an order (Roles > Condition > Script).
Here is a good chart that shows the ACL process

Debugging
If you found this article, you likely are trying to fix a readonly issue.
This is my process for debugging ACLs:
Table or Field. Is this a table-level or field-level issue? Look at related ACLs for issues
Parent Table. Look at parent table ACLs if applicable
Active Flag. Flip the active flag to false on ACLs to find conflicting ACLs. If found, fix the ACL. Remember to flip the active back to true when completed.
Add ACL. Add new ACLs as needed. Sometimes you deactivate an ACL, but that isn’t that often. Don’t delete ACLs, that causes issues later for the most part.
Browser Console. View the Browser Console for errors
Debug Tool. Run the Access Control Debug and other debug tools ServiceNow has.
Other Code. There is other code in ServiceNow that affects security. Look in those areas as well
Client Script
UI Policy
Data Policy
Business Rules
Dictionary
Script Includes
Ask for Help. Community > Consultant > HI Support. I try not to bother HI Support much on ACL issues, but sometimes you do get truly stumped
Here is a helpful table of ACL failure reasons. I highlighted the most common operations.
Operation | Results of failing an ACL rule on object |
---|---|
execute | User cannot execute scripts on a record or UI page. |
create | User cannot see the New UI action from forms. The user also cannot insert records into a table using API protocols such as web services. A create ACL with a condition requiring that a field contain a specific value always evaluates as false. Fields on new records are considered empty until the record is saved. |
read | User cannot see the object in forms or lists. The user also cannot retrieve records using API protocols such as web services. |
write | User sees a read-only field in forms and lists, and the user cannot update records using API protocols such as web services. |
delete | User cannot see the Delete UI action from forms. The user also cannot remove records from a table using API protocols such as web services. |
edit_task_relations | User cannot define relationships between task tables. |
edit_ci_relations | User cannot define relationships between Configuration Item [cmdb_ci] tables. |
save_as_template | Used to control the fields that should be saved when a template is created. |
add_to_list | User cannot view or personalize specific columns in the list mechanic. |
list_edit | User cannot update records (rows) from a list. |
report_on | User cannot create a report on the ACL table. For more information, see Restrict report creation with an ACL rule. |
report_view | User cannot view the content of a report on the ACL table or on the ACL field. For more information, see Restrict report creation with an ACL rule. |
personalize_choices | User cannot right-click a choice list field and select Configure Choices. |
Your thoughts
If made any mistakes in this article, missed something, or have your own way to debug ACLs let me know in the comments below!