In the world of enterprise IT, data security and controlled access aren’t just best practices — they’re non-negotiable. That’s where ServiceNow ACLs (Access Control Lists) step in as silent guardians, ensuring that sensitive data is only visible to those who truly need to see it.

If you’re a ServiceNow admin, developer, or just someone stepping into the ServiceNow security landscape, understanding how ACLs work is your first step toward building a secure, well-structured instance.

In this blog, we’ll break down ACLs in the simplest terms possible, explore how they work, and guide you through best practices to implement them effectively. Let’s get started!

What is a ServiceNow ACL?

An Access Control List (ACL) in ServiceNow is a security mechanism that defines which users can access what data and perform which actions. These controls are evaluated every time a user tries to read, write, create, or delete a record or field.

Think of ACLs as security gates — unless a user has the right credentials, they don’t pass through.

Each ACL rule in ServiceNow applies to:

• A specific table or field
• A specific operation (read, write, create, delete)
• A set of conditions, roles, and optionally, a script

Why Are ACLs Important?

ServiceNow is a powerful platform capable of holding sensitive HR records, IT incidents, customer data, and even financials. Uncontrolled access can lead to:

• Data breaches
• Compliance issues (GDPR, HIPAA)
• Misuse of information
• Operational inefficiencies

By using ACLs, organizations can:
✅ Limit access based on user roles
✅ Restrict access to sensitive tables or fields
✅ Define granular permissions at the record level

How ACLs Work in ServiceNow

When a user tries to interact with data, ServiceNow checks ACLs in a strict order. The system evaluates:

1. Table-level ACLs – Controls access to the entire table
2. Field-level ACLs – Controls access to specific fields in a record
3. Operation type – Such as read, write, create, delete

For access to be granted, all applicable ACLs must evaluate to true.

Each ACL rule can contain:

• Roles – The user must belong to at least one assigned role
• Conditions – Predefined logic using fields
• Scripts – Advanced JavaScript that returns true or false

ACLs follow a short-circuit logic: if any condition fails, access is denied — no exceptions.

Types of ACLs in ServiceNow

Let’s understand the different layers at which ACLs operate:

1. Table-Level ACL

This is the first gatekeeper. If the user fails here, they can’t access anything in that table.

Example: Granting only the itil role the ability to read the Incident table.

2. Record-Level ACL

Adds control at the individual record level within a table.

Example: A user can only read incidents that are assigned to them.

3. Field-Level ACL

Provides the most granular control — on individual fields.

Example: Hide the “Salary” field from users without the hr_admin role.

Pro tip: Even if a user has access to a record, they still need separate ACLs to access each field!

How to Create an ACL in ServiceNow (Step-by-Step)

Let’s walk through a simple example:

Step 1: Navigate to ACLs

Go to System Security > Access Control (ACL)
Click New to create a new access control rule.

Step 2: Select Object and Operation

• Choose Type: Record or Field
• Select the Table
• Select the Operation: Read, Write, Create, Delete

Step 3: Set Roles, Conditions, and Script

• Assign the required roles
• Add a condition (like Assigned to is Me)
• If needed, write a script:

javascriptCopyEdit// Only allow access if the current user is the assigned user
gs.getUserID() == current.assigned_to;

Step 4: Save and Test

Always test using impersonation to confirm the rule behaves as expected.

Real-World Example

Use Case: A company wants to allow only HR managers to access the Employee table and restrict access to the “Salary” field.

Solution:

• Table-level ACL: Grant hr_manager role access to Employee table
• Field-level ACL: Grant hr_manager access to Salary field
• Use a script to check if the user is in the correct department if required

Common Mistakes to Avoid

Avoid these pitfalls when managing ACLs:

• Granting broad roles like admin to solve access issues
• Not testing ACLs for users with different roles
• Using overly complex scripts when conditions would suffice
• Forgetting field-level ACLs
• Using the * wildcard field too freely — this can override specific field ACLs unintentionally

Best Practices for Managing ACLs

Follow the Least Privilege Principle
Only give access users absolutely need.

Use Conditions When Possible
Conditions are easier to manage than scripts.

Test Thoroughly
Always test ACLs in a non-production environment using impersonation.

Document Your ACL Rules
Especially scripted ones — future admins will thank you.

Avoid Using ‘admin’ Role for Testing ACLs
Admins bypass ACLs, so impersonate real users instead.

Conclusion: Secure Your Instance with Smart ACLs

Implementing ServiceNow ACLs isn’t just about ticking off security checkboxes. It’s about creating a platform that’s secure, scalable, and compliant with your organization’s needs.

By following best practices, using conditions smartly, avoiding wildcards, and thoroughly testing with impersonation, you can ensure your platform is protected from data leaks, unauthorized changes, and access vulnerabilities.

Ready to Strengthen Your ServiceNow Security?

At MLE Systems, we help organizations implement secure and scalable ServiceNow solutions that are built for performance and compliance. Whether it’s a fresh implementation or optimizing ACLs across the platform, we’ve got you covered.

👉 Get in touch today to secure your ServiceNow environment the right way.