ACL Rule Conditions and Scripts

ACL Rule Conditions and Scripts in ServiceNow

Why ACL Rule Conditions and Scripts Matter

Access Control Lists (ACLs) are the backbone of data security in ServiceNow. They determine who can read, write, create, or delete records and fields. While basic ACL rules can rely on simple role requirements, real-world security demands are often more nuanced. This is where ACL rule conditions and scripts become essential. They allow administrators and developers to implement fine-grained, dynamic, and context-sensitive access control that goes far beyond static role checks. Without a solid understanding of conditions and scripts in ACLs, you risk either leaving data exposed or over-restricting access in ways that break workflows.

What Are ACL Rule Conditions and Scripts?

Every ACL rule in ServiceNow can evaluate access using three components, checked in the following order:

1. Condition (filter condition) – A declarative, no-code filter applied to the record being accessed. This works like a standard ServiceNow filter/query condition (e.g., active = true, assignment_group is dynamic referencing the current user's groups).

2. Script – A server-side JavaScript block that returns true (grant access) or false (deny access). Scripts have access to the current object (the record being evaluated) and can execute complex logic.

3. Requires Role – A list of roles. The user must possess at least one of the listed roles.

All three components must evaluate to true for the ACL to grant access. If any one returns false, the ACL denies access. This is a critical concept: the relationship between conditions, scripts, and roles within a single ACL rule is AND logic.

How ACL Evaluation Works – The Detailed Flow

When a user attempts to access a resource (table, record, or field), the system identifies all matching ACL rules and evaluates them. Here is the evaluation order within a single ACL rule:

Step 1: Requires Role
The system first checks if the user has at least one of the roles specified in the ACL. If no roles are specified, this check automatically passes (returns true). If roles are specified and the user has none of them, evaluation stops and the ACL denies access.

Step 2: Condition
If the role check passes, the system evaluates the declarative condition. This is the filter-style condition builder entry. If no condition is defined, it passes automatically. If the condition evaluates to false for the current record, the ACL denies access.

Step 3: Script
If both the role and condition checks pass, the system runs the script. If no script is defined (or the script field is empty), it passes automatically. The script must explicitly return true to grant access. If it returns false, access is denied.

Key Point: All three must be true. Think of it as: Role AND Condition AND Script = Access Granted.

Understanding Condition Builder in ACLs

The condition field in an ACL uses the same condition builder interface found throughout ServiceNow. Common patterns include:

- Matching the current user: assigned_to is (dynamic) current user — This ensures a user can only access records assigned to them.
- Matching groups: assignment_group is one of the current user's groups — Grants access based on group membership.
- Field-based conditions: state is less than 7 — Restricts access based on the record's state.
- Empty conditions: If the condition is left blank, it evaluates to true and does not restrict access at this layer.

Conditions are efficient because they are declarative and do not require scripting. They should be preferred over scripts when possible for performance and maintainability.

Understanding Scripts in ACLs

ACL scripts provide the most flexibility. Key objects and variables available in ACL scripts include:

- current – The GlideRecord of the record being accessed.
- answer – A pre-set variable. In some contexts (particularly for field-level ACLs that have already passed a table-level ACL), answer may already be set to true. You can use answer to further refine the result or simply set answer = false or answer = true. The recommended best practice is to use answer as the return mechanism rather than an explicit return statement.

A typical ACL script example:

// Grant access if the current user is the caller or the assigned person
answer = (gs.getUserID() == current.caller_id.toString()) || (gs.getUserID() == current.assigned_to.toString());

Another pattern:

// Deny access if the record is in a closed state
if (current.state == 7) { answer = false; } else { answer = true; }

Important scripting considerations:
- ACL scripts execute frequently and on every record access. Keep them as lightweight as possible.
- Avoid GlideRecord queries inside ACL scripts when possible, as they can severely impact performance, especially on list views where the script runs for every row.
- Use gs.hasRole() sparingly in scripts — it is better to use the Requires Role field for role checks so the system can short-circuit evaluation early.
- Never use gs.log() or heavy logging in production ACL scripts.

How Multiple ACL Rules Interact

When multiple ACL rules match the same resource (same table, same operation), the system uses the following logic:

- If any matching ACL grants access, the user is granted access (OR logic between multiple matching ACLs for the same resource).
- However, remember that within each individual ACL, all three components must pass (AND logic).
- The system also follows the most specific match principle. A field-level ACL takes precedence over a table-level ACL. If a field-level ACL exists, the table-level ACL for the same operation must also pass (both levels are checked).

The Evaluation Hierarchy:
1. Table-level ACL (e.g., incident.*) is checked first.
2. If a field-level ACL exists (e.g., incident.priority), it is checked next.
3. Both must grant access for the user to access that specific field on that record.

Wildcard and Star Rules

- A * (star) ACL on a table applies to all fields that do not have their own explicit field-level ACL.
- If no ACL matches a resource at all and the property glide.sm.default_mode is set to deny (which is the default in most instances), access is denied.

Common Use Cases for ACL Conditions and Scripts

- Record-level security: Allowing users to only read or write their own records (e.g., incidents they reported).
- State-based restrictions: Preventing edits to closed or resolved records.
- Sensitive field protection: Restricting access to fields like SSN or salary based on specific roles AND conditions.
- Dynamic group-based access: Granting access to records assigned to any group the user belongs to.
- Before-business-rule-like enforcement: Preventing certain write operations based on complex business logic.

Debugging ACL Rules

ServiceNow provides the Security Diagnostics page (System Security > Diagnostics) and the ACL debugging feature to troubleshoot access issues. You can enable ACL debugging with security.set_debug true in the application navigator or via session debug. This outputs detailed information about which ACLs were evaluated, what conditions and scripts returned, and the final access decision.

Best Practices

- Use conditions (declarative) before resorting to scripts for better performance.
- Use the Requires Role field for role checks rather than scripting gs.hasRole().
- Keep ACL scripts simple, short, and free of GlideRecord queries when possible.
- Test ACLs by impersonating users with different roles and access levels.
- Document the purpose of each ACL, especially when scripts are involved.
- Remember that an empty condition or empty script evaluates to true, not false.

---

Exam Tips: Answering Questions on ACL Rule Conditions and Scripts

1. Remember the AND relationship: The most commonly tested concept is that within a single ACL rule, the role, condition, and script must ALL be true. If a question asks what happens when the role matches but the script returns false, the answer is access denied.

2. Know the evaluation order: Roles are checked first, then conditions, then scripts. This order matters because the system short-circuits: if the role check fails, the condition and script are never evaluated.

3. Multiple ACLs = OR logic: If two ACL rules apply to the same table and operation, and one grants access while the other denies, the user is granted access. Between multiple matching ACLs, only one needs to pass.

4. Empty fields evaluate to true: A very common trick question. If the condition is blank, it does not deny access. If the script is blank, it does not deny access. Only explicitly false evaluations deny access.

5. Table + Field level: Both the table-level and field-level ACLs must pass for a user to access a specific field. This is a frequent exam topic. If a user passes the table-level ACL but fails the field-level ACL, they cannot see or edit that specific field (but can still access other fields on the record).

6. The answer variable: In ACL scripts, the answer variable is the standard way to return a result. Look for exam questions that test whether you know to use answer = true/false rather than a return statement.

7. Performance awareness: Exam questions may ask about best practices. The correct answer is always to prefer declarative conditions and role fields over scripts, and to avoid GlideRecord queries in ACL scripts.

8. Default deny behavior: Know that when no ACL matches a resource and the default mode is set to deny, the user is denied access. This is the default and secure configuration.

9. Watch for gs.hasRole() in scripts vs. Requires Role field: If a question presents two options — one using gs.hasRole('admin') in a script and another using the Requires Role field — the best practice answer is the Requires Role field.

10. Row-level vs. field-level scenarios: Practice differentiating between scenarios where row-level access (table ACL with a condition like assigned_to is current user) is needed versus field-level restrictions. The exam may present a scenario and ask which type of ACL to create.

11. Read the question for specificity: Exam questions about ACLs often include subtle details about whether a condition is set, a script is present, or roles are assigned. Read every detail — a missing component (left blank) means it evaluates to true, which changes the outcome.

12. Debugging knowledge: You may be asked how to troubleshoot ACL issues. Know that the Security Diagnostics tool and enabling ACL debugging via security.set_debug are the correct approaches.

By mastering the AND logic within a single ACL, the OR logic between multiple matching ACLs, the evaluation hierarchy from table to field level, and the best practices around conditions versus scripts, you will be well-prepared to answer any ACL-related question on the ServiceNow CAD exam.