Table-Level vs Field-Level ACLs

Table-Level vs Field-Level ACLs in ServiceNow: A Complete Guide for CAD Exam Preparation

Why Table-Level vs Field-Level ACLs Matter

Access Control Lists (ACLs) are the backbone of ServiceNow's security model. Understanding the distinction between table-level and field-level ACLs is critical not only for the Certified Application Developer (CAD) exam but also for building secure, production-ready applications. Misconfigured ACLs can lead to unauthorized data exposure, compliance violations, or overly restrictive systems that hinder user productivity. As a developer, you must know how to apply the right type of ACL at the right level to protect sensitive data while maintaining usability.

What Are ACLs in ServiceNow?

An Access Control List (ACL) rule defines who can access what data and what operations they can perform. ACLs are evaluated whenever a user attempts to interact with data in ServiceNow — whether reading, writing, creating, or deleting records. ACLs act as gatekeepers that sit between the user and the data.

ServiceNow ACLs are evaluated based on three key components:
- Object: What is being protected (a table, a field, etc.)
- Operation: What action is being attempted (read, write, create, delete)
- Permissions: Conditions that must be met (roles, conditions, scripts)

What Is a Table-Level ACL?

A table-level ACL controls access to an entire table and all of its records. When you create an ACL rule that specifies only a table name (without a field), it applies broadly to every record in that table for the specified operation.

For example, a table-level ACL on the incident table with a read operation determines whether a user can see any incident records at all. If a user does not pass the table-level ACL check, they will not be able to access any records in that table — period.

Format: [table_name].[operation]
Example: incident.read — Controls who can read records from the Incident table.

What Is a Field-Level ACL?

A field-level ACL controls access to a specific field within a table. This provides granular security, allowing you to show or hide, or make readable or writable, individual fields based on user roles or conditions.

For example, you might want all ITIL users to see incident records, but only managers should be able to view the cost field. A field-level ACL on incident.cost with the read operation would enforce this restriction.

Format: [table_name].[field_name].[operation]
Example: incident.cost.read — Controls who can read the cost field on the Incident table.

How ACL Evaluation Works: The Critical Order

Understanding the evaluation order is one of the most important concepts for the CAD exam:

1. Table-level ACL is evaluated FIRST. If the user fails the table-level ACL, access to the entire table is denied. Field-level ACLs are never even checked.

2. Field-level ACL is evaluated SECOND. Only if the user passes the table-level ACL will ServiceNow proceed to evaluate field-level ACLs for the specific fields being accessed.

This means:
- A user must pass both the table-level and field-level ACL to access a specific field.
- If no field-level ACL exists for a particular field, access to that field is governed solely by the table-level ACL.
- If a field-level ACL exists, the user must satisfy both the table-level ACL and the field-level ACL.

Key Differences Between Table-Level and Field-Level ACLs

Scope:
- Table-level: Applies to the entire table and all records
- Field-level: Applies to a single field within the table

Granularity:
- Table-level: Broad, coarse-grained control
- Field-level: Fine-grained, precise control

Evaluation Priority:
- Table-level: Evaluated first
- Field-level: Evaluated second (only if table-level passes)

Use Case:
- Table-level: Restricting entire tables to specific roles (e.g., only HR staff can access HR cases)
- Field-level: Hiding sensitive fields like SSN, salary, or cost from certain users

Impact of Failure:
- Table-level: User cannot see any data from the table
- Field-level: User can see the record but the specific field is hidden or read-only

How ACL Permissions Are Defined

Each ACL rule can use up to three permission checks, evaluated in this order:

1. Roles: Does the user have the required role? (e.g., itil, admin, hr_manager)
2. Conditions: Does the record meet specified conditions? (e.g., active = true)
3. Scripts: Does a custom script return true? (Advanced logic)

All three checks must pass (AND logic) for the ACL to grant access. If any one fails, access is denied by that ACL rule.

However, if multiple ACL rules exist for the same object and operation, they are evaluated with OR logic — the user only needs to satisfy one of them.

The Wildcard (*) ACL

ServiceNow includes a default wildcard ACL (*.*) that applies to all tables and fields that do not have a more specific ACL defined. By default, this wildcard ACL requires the admin role. This means:

- If no specific ACL exists for a table, only admins can access it.
- Once you create a specific table-level ACL, it takes precedence over the wildcard for that table.
- The most specific ACL always wins.

ACL Evaluation Hierarchy (Most Specific Wins):
1. table.field — Most specific (field-level)
2. table.* — Table-level with wildcard for all fields
3. parent_table.field — Inherited from parent table (if table extends another)
4. parent_table.* — Parent table wildcard
5. *.* — Global wildcard (least specific)

Practical Example

Scenario: You have a custom table called u_employee_records with fields including u_name, u_department, and u_salary.

Requirements:
- All authenticated users with the employee role can read employee records.
- Only users with the hr_admin role can see the salary field.
- Only users with the hr_admin role can create or delete records.

Solution:
- Table-level ACL: u_employee_records.read → Requires role: employee
- Field-level ACL: u_employee_records.u_salary.read → Requires role: hr_admin
- Table-level ACL: u_employee_records.create → Requires role: hr_admin
- Table-level ACL: u_employee_records.delete → Requires role: hr_admin

Result: A user with only the employee role can read records and see all fields except u_salary. A user with hr_admin can see the salary field and also create/delete records.

Important Concepts for the Exam

1. ACLs are processed in order from most specific to least specific. Field-level ACLs are more specific than table-level ACLs.

2. Both table-level AND field-level ACLs must pass. Passing a field-level ACL alone is not sufficient if the table-level ACL fails.

3. The admin role bypasses all ACL checks by default. Users with the admin role have unrestricted access unless high security settings are enabled.

4. ACLs respect table inheritance. If table B extends table A, and table A has ACLs, those ACLs apply to table B as well unless table B has its own more specific ACLs.

5. Creating a record requires both create and write ACLs. The create operation is checked first, then write ACLs apply to individual fields being set during creation.

6. ACLs are only evaluated when the system property glide.sm.enforces_acl is set to true (which is the default for most instances).

7. Row-level ACLs use conditions or scripts at the table level to restrict access to specific records (rows), not just entire tables. This is still technically a table-level ACL but with a condition that filters which records the user can access.

Debugging ACLs

ServiceNow provides a built-in Security Diagnostics tool (accessible via the session debug module or by navigating to System Diagnostics > Session Debug > Debug Security). Enabling security debugging outputs detailed ACL evaluation information to the system log, showing which ACLs were evaluated, in what order, and whether they passed or failed. This is invaluable for troubleshooting access issues.

You can also use the Access Control (ACL) module under System Security to view and manage all ACL rules.


Exam Tips: Answering Questions on Table-Level vs Field-Level ACLs

1. Remember the evaluation order: Table-level ACLs are ALWAYS checked before field-level ACLs. If a question asks what happens when a user fails a table-level ACL but passes a field-level ACL, the answer is: access is denied. The field-level ACL is never even reached.

2. Look for the word "specific": When a question mentions restricting access to a specific field, the answer almost always involves a field-level ACL. When it mentions restricting access to an entire table, it involves a table-level ACL.

3. Watch for trick questions about admin: If a question mentions a user with the admin role, remember that admins bypass ACLs by default. The answer for admin access is almost always "access is granted" unless the question specifically mentions high security plugins or elevated privilege configurations.

4. Understand the AND/OR logic: Multiple permission checks within a single ACL rule use AND logic (role AND condition AND script must all pass). Multiple ACL rules for the same object use OR logic (the user only needs to pass one of them). This is a common exam trap.

5. Inheritance matters: If a question involves extended tables, remember that child tables inherit ACLs from parent tables. A more specific ACL on the child table overrides the parent's ACL for that same object and operation.

6. Default behavior without ACLs: If no ACL exists for a table, the wildcard ACL (*.*) applies, which requires the admin role. So if a question asks what happens when no ACL is defined for a custom table, the answer is: only admins can access it.

7. Read the question carefully for the operation: ACLs are operation-specific (read, write, create, delete). A user might have read access but not write access. Make sure you identify which operation the question is asking about.

8. Distinguish between visibility and editability: Read ACLs control whether a user can see data. Write ACLs control whether a user can modify data. A field can be visible (read ACL passes) but not editable (write ACL fails). This distinction comes up frequently in exam questions.

9. Know that ACLs apply to all access methods: ACLs protect data regardless of whether the user accesses it through the UI, REST API, web services, or other means. This is a key security concept that may appear on the exam.

10. Practice scenario-based thinking: Many CAD exam questions present a scenario and ask you to choose the correct ACL configuration. Break the scenario down: What table? What field? What operation? What role? Then match it to the appropriate ACL type and configuration.


Summary

Table-level and field-level ACLs work together to form a layered security model in ServiceNow. Table-level ACLs provide broad access control over entire tables, while field-level ACLs offer granular control over individual fields. Both must be satisfied for a user to access a specific piece of data. Understanding this hierarchy, the evaluation order, and the nuances of ACL configuration is essential for passing the CAD exam and building secure ServiceNow applications.