Access Control Lists (ACLs) in ServiceNow – Complete Guide for CAD Exam
Why Are Access Control Lists (ACLs) Important?
Access Control Lists (ACLs) are the backbone of security in the ServiceNow platform. They determine who can access what data and what operations they can perform on that data. Without properly configured ACLs, sensitive data could be exposed to unauthorized users, or critical records could be modified or deleted by those who should not have permission. Understanding ACLs is essential for any ServiceNow developer because:
• They protect data integrity across the entire platform.
• They enforce the principle of least privilege, ensuring users only see and do what they need to.
• They are evaluated on every transaction — every read, write, create, and delete operation passes through the ACL engine.
• Misconfigured ACLs are one of the most common causes of security vulnerabilities in ServiceNow instances.
What Are Access Control Lists (ACLs)?
An Access Control List (ACL) is a security rule that defines the conditions under which a user can access a specific resource in ServiceNow. ACLs are also commonly referred to as Access Control Rules or simply security rules. Each ACL rule specifies:
• Object: The resource being protected (e.g., a table, a field on a table, or a specific record).
• Operation: The type of access being controlled — read, write, create, delete, or execute.
• Permissions: The conditions that must be met for access to be granted. These can be defined through roles, conditions, and/or scripts.
ACLs exist at multiple levels:
1. Table-level ACLs: Control access to an entire table (e.g., can a user read the Incident table?).
2. Field-level ACLs: Control access to specific fields on a table (e.g., can a user write to the Priority field on the Incident table?).
3. Record-level ACLs: Use conditions or scripts to restrict access to specific records within a table.
How Do ACLs Work?
ServiceNow evaluates ACLs using a specific process whenever a user attempts to access a resource. Here is how the evaluation works:
1. The ACL Evaluation Order (Most Specific to Least Specific)
When a user tries to access a resource, the system looks for the most specific matching ACL rule first, then works its way up to more general rules:
• Match on table and field (e.g., incident.priority) — most specific
• Match on table only (e.g., incident.*) — less specific
• Match on wildcard (e.g., *.*) — least specific (the catch-all rule)
If a field-level ACL exists, both the field-level ACL and the table-level ACL must pass for access to be granted. This is a critical concept — ACLs are cumulative from table level to field level.
2. The Three Permission Checks Within an ACL Rule
Each ACL rule contains up to three permission checks, and all specified checks must pass for the ACL to grant access:
• Roles: Does the user have the required role(s)? If roles are specified, the user must possess at least one of them.
• Conditions: Does the record meet certain field-based conditions? (e.g., active = true)
• Script: Does a server-side script return true? This allows for complex logic beyond simple conditions.
If no roles, conditions, or scripts are specified in an ACL rule, then any authenticated user passes that rule.
3. The Role of the Admin
By default, users with the admin role bypass most ACL checks. However, the security_admin role is required to modify ACL rules themselves. To elevate to the security_admin role, an admin must explicitly activate it via the Elevate Privileges dialog.
4. The High Security Plugin
When the High Security Settings plugin is enabled, additional restrictions are enforced, such as requiring the security_admin role to be elevated before making changes to ACLs, and tighter controls on debugging.
5. What Happens When No ACL Exists?
This depends on the system property glide.sm.default_mode:
• If set to allow (not recommended for production): Access is granted if no matching ACL rule is found.
• If set to deny (recommended and default for new instances): Access is denied if no matching ACL rule is found.
This is a frequently tested concept on the exam.
6. Debugging ACLs
ServiceNow provides a Security Diagnostics tool (accessible via the session debug options, e.g., Debug Security) that logs ACL evaluation results. This is extremely helpful when troubleshooting why a user can or cannot see specific data. You can enable debugging by navigating to System Diagnostics > Session Debug > Debug Security.
Key Concepts to Remember
• ACLs are processed from most specific to least specific.
• Both the table-level and field-level ACLs must pass for a field to be accessible.
• Within a single ACL rule, all specified checks (roles, conditions, scripts) must pass.
• An empty ACL (no roles, no conditions, no scripts) grants access to all authenticated users.
• The *.* wildcard ACL serves as the default catch-all rule.
• ACLs only apply to the server side; they are the true security enforcement. Client-side scripts (like UI Policies) are cosmetic and can be bypassed.
• ACLs apply to data accessed via lists, forms, web services, and APIs — they are universally enforced at the platform level.
Creating an ACL Rule — Step by Step
1. Navigate to System Security > Access Control (ACL).
2. Click New.
3. Select the Operation (read, write, create, delete, execute).
4. Select the Type (typically record).
5. Choose the Table (e.g., incident).
6. Optionally choose a Field for field-level security.
7. Add Roles in the Requires role section.
8. Add Conditions if needed.
9. Add a Script if advanced logic is required (the script must set answer = true or answer = false).
10. Save the record. You may need to elevate to security_admin to do this.
Exam Tips: Answering Questions on Access Control Lists (ACLs)
Here are essential tips to help you confidently answer ACL-related questions on the ServiceNow Certified Application Developer (CAD) exam:
• Remember the evaluation order: Field + Table level ACLs → most specific match first. If there is a field-level ACL, the table-level ACL must also pass. This is tested frequently.
• Know the default behavior: When no ACL exists and glide.sm.default_mode is set to deny, access is denied. If set to allow, access is granted. Expect a question on this.
• Understand the three checks: Roles AND Conditions AND Script must ALL pass within a single ACL rule. If any one fails, the ACL denies access.
• Empty ACL = access for authenticated users: If an ACL has no roles, no conditions, and no script, any logged-in user will pass that ACL. This is a common trap in exam questions.
• Admin role bypasses ACLs: But the security_admin role is needed to edit ACL rules. Remember the Elevate Privileges mechanism.
• Client-side is not security: If a question asks about the most secure way to restrict access, the answer is always ACLs — not UI Policies, Client Scripts, or Data Policies (unless the data policy is applied on the server side for validation, not access control).
• ACLs protect all access channels: They apply to forms, lists, REST APIs, SOAP, import sets, etc. If a question mentions protecting data from API access, ACLs are the answer.
• Know the operations: Read, Write, Create, Delete, Execute. Write does not include Create — they are separate operations. A user may be able to edit existing records but not create new ones.
• Wildcard rules: The *.* rule is the global default. The table.* rule applies to all fields on a specific table. Questions may ask about inheritance and how wildcard rules interact with specific rules.
• Debugging: If a question asks how to troubleshoot ACL issues, the answer is typically Debug Security or the Security Diagnostics tool. Be familiar with session debug modules.
• Watch for tricky wording: Questions may describe a scenario where a user has a role but a condition fails — the correct answer is that access is denied because all checks must pass.
• Before/After Business Rules vs. ACLs: Business Rules run logic; ACLs enforce access. Do not confuse them. ACLs are evaluated before the data is returned to the user.
• Practice scenario-based questions: The exam often presents scenarios like: A user can see a table but not a specific field. What is the most likely cause? The answer would be a field-level ACL restricting access to that field for users without the required role.
By mastering these concepts and tips, you will be well-prepared to handle any ACL-related question on the CAD exam with confidence.