1. Introduction

ServiceNow Access Control Lists (ACLs) are the primary server-side security mechanism for controlling who can access ServiceNow data and functionality. A scalable ACL architecture should follow a defense-in-depth model:

• Roles define broad authorization.
• Table and record ACLs control access to records.
• Field ACLs protect sensitive information.
• Conditions provide declarative, data-based restrictions.
• Scripts handle complex authorization logic.
• Query Business Rules can filter records at query time where appropriate.
• Application Access controls cross-scope application access.
• Data Policies and Business Rules complement ACLs but should not replace server-side authorization.

The fundamental principle is: Security must be enforced on the server. Never rely on UI Policies, Client Scripts, hidden fields, or form configuration as the primary security mechanism.  ACLs establish the server-side authorization boundary.

 

1. ServiceNow ACL Security Architecture

A recommended enterprise security architecture is:

 

For a large enterprise implementation, security should be organized into:

 

1. ACL Evaluation Model

Understanding ACL evaluation is critical for designing and troubleshooting security.

For a request involving a field such as incident.assigned_to, ServiceNow evaluates increasingly general ACL definitions, including:

1. incident.assigned_to
2. incident.*
3. Parent-table ACLs such as task.assigned_to and task.*
4. *.assigned_to
5. *

The table-level and field-level security requirements must both be satisfied for field access.

 

Within an individual ACL, the major authorization checks are:

• Role -> Condition-> Script
• Roles and conditions should be evaluated before expensive scripts.

Important rule: ACLs at the same level

Multiple ACLs at the same specificity level can effectively provide alternative authorization paths. Therefore, if one ACL grants access, another restrictive ACL at the same level does not necessarily override it.

 

This is one of the most common causes of unexpected access.

For example:

ACL #1 → x_app.user → ALLOW

ACL #2 → x_app.manager → DENY

A manager who also has x_app.user may still receive access through ACL #1.

Therefore:    Avoid overlapping ACLs with conflicting security intent.

 

1. ACL Operations

Common ACL operations include:

Operation

|

Purpose

|
|

Read

|

View records or fields

|
|

Write

|

Modify existing records or fields

|
|

Create

|

Insert new records

|
|

Delete

|

Delete records

|
|

List

|

Control list access where applicable

|
|

Execute

|

Control executable resources

|
|

Report access

|

Control reporting capabilities

|
|

List edit

|

Control inline list editing

|
|

REST Endpoint

|

Protect Scripted REST resources

|
|

Client Callable Script Include

|

Protect GlideAjax access

|

 

An important design rule is:

Write access does not automatically mean Create access.

Create and write should be explicitly designed according to the security matrix.

 

1. ACL Security Layers

A scalable architecture should use the following layers:

Layer

|

Purpose

|

Example

|
|

Role

|

Establish broad authorization

|

x_app.agent

|
|

Table ACL

|

Control access to table

|

Who can read the request

|
|

Record/condition

|

Restrict records

|

Requester can read own records

|
|

Script

|

Complex authorization

|

Manager of record's department

|
|

Field ACL

|

Protect sensitive fields

|

Only HR security can read salary

|
|

Query BR

|

Filter queried records

|

Show only user's records

|
|

Application Access

|

Control cross-scope access

|

Application scope restrictions

|
|

Business Rules

|

Additional server-side controls

|

Prevent invalid state changes

|

 

The preferred authorization hierarchy is:

Role → Condition → Script

Use scripts only when declarative security cannot adequately express the requirement.

 

1. Role-Based vs. Data-Based Authorization

Before creating an ACL, determine what type of authorization is required.

Role-based authorization

Example:

Only application administrators can modify this field.

Use:

Requires role:

x_company_dd.security_admin

 

Data-based authorization

Example:

Users can modify records assigned to their assignment group.

Use a condition or script based on the record's data.

 

Relationship-based authorization

Example:

A manager can view cases belonging to employees in the manager's department.

This generally requires more complex logic and may require an ACL script.

 

1. Recommended Role Architecture

Avoid using admin as the solution for every application security requirement.

Instead, define application-specific roles such as:

x_company_dd.user

x_company_dd.requester

x_company_dd.agent

x_company_dd.manager

x_company_dd.admin

x_company_dd.security_admin

x_company_dd.integration

 

A recommended hierarchy is:

 

 Tier 1:  x_company_dd.user       

           Tier 2: x_company_dd.requester         

           Tier 2: x_company_dd.agent                      

           Tier 2: x_company_dd.manager  

                   Tier 3:x_company_dd.admin

 

Role hierarchies can reduce the number of roles that must be explicitly referenced in individual ACLs.

This produces a more scalable RBAC + ABAC model than granting broad admin access.

 

1. ACL Design Methodology

Before implementing an ACL, answer five questions.

Step 1 — What resource is protected?

Example:

Table: dd_request

Field: work_notes

Operation: write

Step 2 — Who should have access?

Example:

x_company_dd.admin

Step 3 — Who should not have access?

Example:

All non-administrative users

Step 4 — What operation is required?

Determine whether access is:

Create

Read

Write

Delete

List

Execute

Step 5 — Is authorization role-based or data-based?

Examples:

Role-based:

User has x_company_df.admin

 

Data-based:

User belongs to assignment group

 

Relationship-based:

User is manager of requested_for

This analysis determines whether to use a role, condition, or script.

1. Create an ACL Security Matrix

Before configuring ACLs, create an authorization matrix.

Persona

|

Role

|

Read

|

Write

|

Create

|

Delete

|

Row Scope

|
|

Requester

|

x_app.requester

|

Own

|

Own/open

|

Yes

|

No

|

Own records

|
|

Fulfiller

|

x_app.fulfiller

|

Assigned group

|

Assigned group

|

Yes

|

No

|

Assignment group

|
|

Manager

|

x_app.manager

|

All

|

All

|

Yes

|

No

|

Department

|
|

Admin

|

x_app.admin

|

All

|

All

|

Yes

|

Yes

|

All

|

For a sensitive field:

Resource

|

Operation

|

Role

|

Condition

|

Script

|
|

df_request

|

Read

|

Requester

|

Own record

|

No

|
|

df_request

|

Write

|

Agent

|

Assignment group

|

Yes if needed

|
|

df_request

|

Delete

|

Admin

|

None

|

No

|
|

work_notes

|

Write

|

Admin

|

None

|

No

|
|

confidential_data

|

Read

|

Security Admin

|

None

|

No

|

This matrix becomes the security design baseline.

1. Implementation Steps

Step 1 — Establish the development environment

For scoped applications:

• Develop in the appropriate application scope.
• Use Studio/Application development tools.
• Use an Update Set where appropriate.
• Elevate to security_admin when required to create or modify ACLs.

Step 2 — Identify existing ACLs

Before creating a new ACL, check:

• Table ACLs
• Parent-table ACLs
• Field ACLs
• Wildcard ACLs
• Existing application security
• Existing roles
• Existing Query Business Rules

This prevents duplicate or conflicting authorization logic.

Step 3 — Create table-level ACLs

Create separate ACLs for the required operations:

x_app_ticket.read

x_app_ticket.write

x_app_ticket.create

x_app_ticket.delete

 

For example:

Type: Record

Operation: read

Name: x_app_ticket

Requires role: x_app.fulfiller

Condition: as required

Script: only if required

Repeat for the required operations.

 

1. Use Conditions Before Scripts

Suppose the requirement is:

Requester can read only their own requests.

If this can be expressed declaratively, prefer a condition such as:

Opened by = Me

instead of a script. Use a script when authorization depends on complex relationships.

 

For example:

answer = false;

 

if (current.opened_by == gs.getUserID()) {

    answer = true;

} else if (current.assignment_group &&

           gs.getUser().isMemberOf(current.assignment_group)) {

    answer = true;

}

ACL scripts should be lightweight, always explicitly set answer, and avoid expensive database operations.

 

1. Field-Level Security

Field ACLs are appropriate for sensitive information such as:

• Salary
• SSN
• Financial information
• Security information
• Confidential customer information
• Sensitive HR information

Example:

x_app_hr_case.salary

Operation: read

Role: x_app.hr_admin

Also define the corresponding write ACL when appropriate.

Remember:

A field ACL does not replace the table-level ACL. Both levels must provide the necessary access.

1. Example: dd_request Work Notes

A common requirement is:

Only administrators can write to the Work Notes field on the custom dd_request table.

Recommended design:

dd_request

     |

     +--- work_notes

             |

             +--- write ACL

                     |

              x_company_dd.admin

                     |

                 ALLOW

 

Configuration:

Type: Record

Name: dd_request.work_notes

Operation: write

Requires role: x_company_dd.admin

Prefer the role configuration over hard-coding:

gs.hasRole('admin')

 

inside the ACL script.

For an enterprise application, an application-specific role such as:

x_company_dd.admin

 

provides better security governance and maintainability.

1. Assignment Group Access

Suppose users can update df_request only when they belong to the Assignment Group.

Conceptually:

answer = false;

 

if (current.assignment_group) {

    answer = gs.getUser().isMemberOf(current.assignment_group);

}

 

1. Query Business Rules and List Filtering

ACLs determine authorization, but Query Business Rules can be useful when the requirement is to restrict which rows are returned by a query.

For example:

(function executeRule(current, previous) {

 

    if (!gs.hasRole('x_app.manager')) {

        var qc = current.addQuery(

            'opened_by',

            gs.getUserID()

        );

 

        qc.addOrCondition(

            'assignment_group.u_members',

            'CONTAINS',

            gs.getUserID()

        );

    }

 

})(current, previous);

Query Business Rules can filter records at query time rather than relying solely on ACL scripts to hide rows after the query. This can be important for list behavior, pagination, and avoiding exposure of aggregate information such as row counts.

However:

Query Business Rules complement ACLs; they should not be treated as a replacement for authorization ACLs.

1. Application Access and Scoped Applications

For scoped applications, two separate security gates may apply:

Application Access

Controls cross-scope access:

Accessible from:

1. This application scope only
2. All application scopes

and controls whether other scopes can:

• Read
• Create
• Write
• Delete

ACL

Controls user-level authorization.

Therefore:

 

Both controls must be considered in the design.

1. API and Integration Security

ACL architecture must extend beyond the ServiceNow user interface.

Scripted REST APIs

Use:

• Authentication
• ACL authorization
• REST Endpoint ACL
• Dedicated integration role

Example:

x_app.integration

Do not give an integration account admin merely to make an integration work.

GlideAjax / Script Includes

For client-callable Script Includes:

• Enable Client Callable only when required.
• Configure the appropriate client-callable ACL.
• Validate authorization inside the server-side method.

Server-side scripts

When user-facing logic needs to respect ACLs, use:

GlideRecordSecure

or explicitly check:

canRead()

canWrite()

rather than assuming a normal GlideRecord query enforces user ACLs.

 

1. ACL Use Cases

Use Case 1 — ITSM Incident

Incident

 |

 +--- Read → ITIL users

 |

 +--- Write → Assigned group

 |

 +--- Delete → Admin

 |

 +--- Sensitive fields → Security role

 

Use Case 2 — HRSD

HR Case

 |

 +--- Employee → Own cases

 |

 +--- HR Agent → Assigned cases

 |

 +--- HR Manager → Department cases

 |

 +--- HR Admin → All cases

 

Use Case 3 — CMDB

CMDB CI

 |

 +--- Read → Authorized users

 |

 +--- Write → Discovery / integrations

 |

 +--- Manual update → CMDB administrators

 |

 +--- Delete → CMDB governance/admin

Unrestricted CMDB write access can negatively affect data quality, reconciliation, and governance.

For a mature CMDB/CSDM implementation, this is particularly important because authoritative sources, IRE, Discovery, Service Mapping, integrations, and manual maintenance must have clearly defined ownership.

 

Use Case 4 — Security Operations

Security Incident

 |

 +--- Security Analyst → Read/Write

 |

 +--- Manager → Read

 |

 +--- Employee → No access

 |

 +--- Security Admin → Full access

 

Use Case 5 — Procurement

Purchase Request

 |

 +--- Requester → Read own request

 |

 +--- Procurement → Read/Write

 |

 +--- Approver → Read/Approve

 |

 +--- Admin → Full access

 

Use Case 6 — Confidential Data

Customer

 |

 +--- Name → Normal access

 +--- Phone → Normal access

 +--- SSN → Restricted

 +--- Financial Data → Restricted

 +--- Security Information → Security role

 

Use Case 7 — Record Ownership

Users can read only their own records.

ALLOW if:

Admin

OR

Requested For = Current User

OR

User belongs to Assignment Group

OR

User has application-specific role

 

Use Case 8 — Closed Record Protection

Requirement:

Users cannot modify a closed record, but administrators can.

Use:

General write ACL:

state != Closed

 

Administrative write ACL:

x_app.admin

Because alternative ACL paths can grant acc

 

Summary

A well-designed ACL architecture is critical to ServiceNow because it establishes consistent, secure, and scalable access to data and functionality. Proper ACL design ensures users can access only the records and fields appropriate to their roles, while preventing unauthorized access or data exposure. It also minimizes conflicting or overly complex security rules, improves platform performance, simplifies maintenance, and supports compliance requirements. A clear ACL strategy should follow least-privilege principles, use roles and conditions appropriately, and align with the overall ServiceNow security and governance architecture.