AnAccess Control rule (ACL)in ServiceNow defineswho can access dataandwhat actions they can performon that data. Each ACL consists of three primary components:
Object being secured– The specific table, field, or record that the rule applies to.
Operation– The type of action that is being secured (e.g., Read, Write, Create, Delete).
Permissions required– The conditions, roles, or scripts that determine whether access is granted.
ACLs evaluatewhether a user has permissionto access a specific table, field, or action.
Thesecurity rules are processed from most specific to least specific(e.g., field-level > table-level).
Permissions can be granted based onroles, conditions, or custom scriptsusing GlideSystem (gs).
A. Groups, Conditional Expressions, and Workflows(Incorrect)
ACLs do not manageworkflowsor directly control group assignments.
B. Table Schema, CRUD, and User Authentication(Incorrect)
CRUD (Create, Read, Update, Delete) permissions are controlled by ACLs, butUser Authenticationis managed separately through login policies (LDAP, SSO, etc.).
D. security_admin(Incorrect)
security_adminis aspecial elevated rolerequired to modify security settings, but it is not what an ACL specifies.
Access Control Rules Overview:https://docs.servicenow.com/en-US/bundle/utah-platform-security/page/administer/security/concept/access-control-rules.html
Configuring ACLs in ServiceNow:https://docs.servicenow.com/en-US/bundle/utah-platform-security/page/administer/security/task/t_CreateOrModifyAnAccessControl.html
How ACLs Work in ServiceNow:Explanation of Incorrect Options:Official References from Certified System Administrator (CSA) Documentation:
