August 29,2024
ACL
Documentation
What is ACL?
Access Control List (ACL) in ServiceNow is a set of rules that restrict access
to data by controlling what users can see or do within the system. ACLs are
an essential part of ServiceNow security and ensure that users only have the
necessary permissions to perform their tasks.
Anyone without “security_admin” role cannot do anything in the ACL part.
Someone with security_admin role can assign anyone as “security_admin”.
If we check, “Admin overrides” then the ACL doesn’t apply for admin.
Steps to Create the ACL:
1. Navigate to Access Control List (ACL):
I start by going to System Security > Access Control (ACL) in
the ServiceNow application navigator.
2. Create a New ACL Rule:
I click on the New button to create a new ACL rule.
3. Define Basic ACL Details:
Table: I select Incident from the table dropdown because this
ACL will apply to the Incident table.
Type: I choose Record because I want to control access to the
entire record, and then I’ll use a script to target the specific field.
4. Set the Operation:
Operation: I select write to control the ability to edit the
record, including its fields.
5. Write the Script:
In the Script section, I enter the following JavaScript code:
// Check if the user has the admin role
if (gs.hasRole('admin')) {
// Allow access if the user is an admin
answer = true;
} else {
// Deny access if the user is not an admin
answer = false;
}
This script checks if the user has the admin role. If they do, the
script allows them to edit the record, which includes the email ID
field. If not, access is denied.
6. Add a Description:
In the Description field, I provide additional context for the ACL
rule. I might enter something like " Allow write for u_email_id in
incident, if the ACL script returns true."
7. Save the ACL:
I click Submit to save the ACL rule.
This setup ensures that only users with the admin role can edit any record in
the Incident table, including the email ID field, effectively meeting the
requirement.
Testing
I used a user created by me with “incident_manager” role and while
impersonating him, I could not edit “email_id” which surely identifies the
successful implementation.