What is Access Control in ServiceNow: An Overview

By /

Unlocking the Gates: A Deep Dive into Access Control in ServiceNow

Imagine a bustling city, full of vital services, sensitive data, and countless operations running smoothly. Now, picture what would happen if every door was unlocked, every vault open, and anyone could walk into any building and do anything they pleased. Chaos, right?

That’s precisely why access control isn’t just a nice-to-have; it’s the bedrock of any secure and functional enterprise platform. And in the world of ServiceNow, where critical IT, HR, Customer Service, and even custom business processes reside, mastering access control is paramount. It’s about ensuring the right people have the right access to the right information at the right time – and absolutely nothing more.

Whether you’re a fresh ServiceNow developer, an experienced administrator, or just someone looking to understand the mechanics behind the curtain, you’ve landed in the right place. We’re about to demystify ServiceNow’s access control mechanisms, turning complex concepts into practical, human-understandable insights. We’ll cover everything from the basic building blocks to advanced concepts, best practices, and even how to troubleshoot those head-scratching “why can’t I see this?” moments.

So, grab your coffee, get comfortable, and let’s unlock the gates to effective access control in ServiceNow!

The Foundational Pillars: Users, Groups, and Roles

Before we can talk about locking down specific data, we need to understand who we’re locking it down for, and what kind of “keys” they’ll carry. In ServiceNow, this involves three core components: Users, Groups, and Roles.

Users: The Individuals in Your ServiceNow Ecosystem

Every person who interacts with your ServiceNow instance is a user. Simple as that. From the IT technician resolving incidents to the HR manager onboarding new employees, each has a unique digital identity.

  • User Table Name: In ServiceNow, all user information is stored in the sys_user table. This is your go-to for all things user-related.
  • Creating User Accounts: While typically integrated with corporate directories like Active Directory, you can also create user accounts manually or via script.
    • var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.user_name = 'jdoe'; // Use user_name for the login ID
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();

    Note: In recent ServiceNow versions, the login ID field is typically user_name, not username. Always verify field names for your specific instance version.

  • The ‘Web Services User’: A Special Case: Ever seen a user account with “Web Services Access Only” checked? This isn’t your typical human user. A web services user is a dedicated account granted to a third-party application or integration to connect to ServiceNow. The crucial part? This user cannot log in to ServiceNow via the standard UI. Their sole purpose is to facilitate secure, programmatic communication. This is a common interview question: “What is a web services user and when is it used?” The answer lies in secure system-to-system integrations, not human interaction.

Groups: The Power of Collaboration and Efficiency

While users are individuals, work in any organization is almost always a team effort. This is where groups come in. A group is a collection of users who share a common purpose, role, or set of permissions. Think of your IT Help Desk, HR Specialists, or Project Managers – these are natural groups.

  • Group Table Name: Group definitions are stored in the sys_user_group table.
  • Creating Groups:
    var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group'; // Descriptive name for the group
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // SYS_ID of the manager user
newGr.email = 'testing@yourcompany.com';
newGr.description = 'Group for testing purposes';
newGr.insert();

    Pro-Tip: Always provide a clear name and description for your groups. It makes management much easier down the line.

  • Managing Group Members: Adding and removing users from groups is a frequent task. The membership itself is recorded in the sys_user_grmember table.
    • // Adding a Group Member
var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // SYS_ID of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // SYS_ID of the group
grMem.insert();

// Removing a Group Member
var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // SYS_ID of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // SYS_ID of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
  • Checking Group Membership: A common requirement in scripts or conditions is to determine if the currently logged-in user belongs to a specific group.
    if (gs.getUser().isMemberOf('Service Desk')) {
    gs.addInfoMessage('Welcome, Service Desk agent!');
} else {
    gs.addErrorMessage('Access denied. You are not a Service Desk member.');
}

    This little gem, gs.getUser().isMemberOf('group name'), returns true or false and is incredibly useful for dynamic access checks within UI policies, client scripts (with caution), or server-side logic.

Roles: The Definition of Permissions

Roles are where the rubber meets the road. A role in ServiceNow is a collection of permissions that grants access to specific features, records, or functions. They don’t represent a person or a team, but rather *what* a person can do.

  • The Golden Rule: Assign Roles to Groups, Not Users! This is not just a best practice; it’s a fundamental principle for scalable and maintainable access control.

    • Why is this the best practice? Imagine you have 50 users in your “IT Incident Resolvers” team, and they all need the itil role. If you assign the itil role to each of those 50 users individually:

    1. Onboarding: When a new Resolver joins, you have to remember to add the itil role to their user account.
    2. Offboarding: When a Resolver leaves, you have to remember to remove the itil role from their user account. If you forget, it’s a potential security vulnerability.
    3. Updates: If the “IT Incident Resolvers” team suddenly needs a new role (e.g., knowledge_manager), you’d have to add it to all 50 users individually.

    Now, consider assigning the itil role to the “IT Incident Resolvers” group. Then, you simply add users to and remove users from that group. When an employee leaves and you remove them from the group, all roles associated with that group are automatically removed from their profile. This drastically simplifies management, reduces errors, and improves security. This distinction is a frequent interview topic, so be ready to explain the “why.”

  • Adding Roles to Users/Groups via Script:

    When you assign a role, a record is created in either the sys_user_has_role (for users) or sys_group_has_role (for groups) table.

    // Adding a Role to a User (less common, but possible)
var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // SYS_ID of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // SYS_ID of the role
userRole.insert();

// Adding a Role to a Group (the preferred method!)
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // SYS_ID of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // SYS_ID of the role
grpRole.insert();

Access Control Lists (ACLs): The Ultimate Gatekeepers

If users, groups, and roles define *who* has access and *what types* of permissions they have, then Access Control Lists (ACLs) are the granular rules that dictate *what specific data* they can interact with, and *how* they can interact with it. ACLs are the heart of ServiceNow’s security framework, acting like highly intelligent bouncers at the door of every record and field.

What Exactly Are ACLs?

An ACL is a security rule that restricts access to a record or a field. It specifies:

  • The object: A table, a specific field on a table, or even a UI Page.
  • The operation: What action is being controlled (e.g., read, write, create, delete).
  • The conditions: What criteria must be met for access to be granted (e.g., user has a specific role, user is in a specific group, a field value is true).

To work with ACLs, you need a powerful key: the security_admin role. This role provides elevated privileges to create, modify, and delete ACLs. It’s a highly sensitive role, often requiring separate elevation within an instance, so use it judiciously!

ACL Operations: Defining the “How”

ACLs aren’t just about allowing or denying overall access. They’re incredibly granular, defining specific types of interactions. Here are the most common and crucial ACL operations:

  • read: Controls whether a user can view an object (record or field) in forms, lists, or retrieve it via APIs. If you can’t read it, you can’t see it.
  • write: Governs whether a user can modify an object. If denied, fields appear read-only in forms/lists, and updates via API are blocked. You can see it, but you can’t change it.
  • create: Determines if a user can create new records in a table (e.g., see the “New” UI action, insert via API). You can’t add new items.
  • delete: Controls if a user can remove records from a table (e.g., see the “Delete” UI action, delete via API). You can’t get rid of items.
  • execute: Prevents users from executing scripts on a record or UI page. Often used for more advanced security scenarios.
  • list_edit: Specifically controls whether a user can update records directly from a list view. That handy pencil icon in lists? This ACL controls it.
  • report_on: Stops users from creating reports on the object. Crucial for sensitive data.
  • personalize_choices: Prevents a user from right-clicking a choice list field and modifying its options.
  • edit_task_relations / edit_ci_relations: Control the ability to define relationships between task tables or Configuration Item (CMDB CI) tables.
  • save_as_template: Controls which fields are saved when a user creates a template.
  • add_to_list: Restricts whether a user can view or personalize specific columns in a list.

Understanding these operations is key to truly securing your data. For interviews, be prepared to name and briefly describe the most common ones (read, write, create, delete).

The Hierarchy: Table vs. Field ACLs

ServiceNow evaluates ACLs in a specific order. This hierarchy is critical to understand, as it can be a source of confusion if you’re not aware of it:

  1. Table-level ACLs first: ServiceNow checks access to the entire table (e.g., incident.* or incident.none).
  2. Field-level ACLs second: If table access is granted, ServiceNow then checks access to specific fields on that table (e.g., incident.short_description).

Here’s the golden rule from the reference:

  • “A user must pass both field and table ACL rules in order to access a record object.”
  • “If a user fails a field ACL rule but passes a table ACL rule, the user is denied access to the field described by the field ACL rule.”
  • “If a user fails a table ACL rule, the user is denied access to all fields in the table even if the user previously passed a field ACL rule.”

Practical Example:
A user has a role that grants them read access to the incident table (incident.none ACL passes).
However, there’s a field ACL denying them read access to the incident.comments field.
Result: The user can see all incident details *except* the comments field, which will be hidden or empty.
Now, if that same user fails the incident.none ACL for read, they won’t even see any incident records at all, regardless of any field ACLs that might have granted them access to specific fields.

Automatic ACL Creation: When You Create a New Table

Ever noticed that when you create a new table in ServiceNow (via the Table Wizard), it seems to come with some ACLs pre-made? That’s not magic! By default, if the “Create access controls” checkbox is checked, ServiceNow will automatically create four basic ACLs for your new table:

  • [your_table_name].none for create operation
  • [your_table_name].none for read operation
  • [your_table_name].none for write operation
  • [your_table_name].none for delete operation

These initial ACLs typically grant access to users with the admin role and potentially other specific roles. If you uncheck that box, no default ACLs are created, meaning you’ll need to create them manually to grant any access to your new table – a task often overlooked, leading to “no access” issues.

Scripting for Access Control: Power and Precision

While the UI allows for easy management of users, groups, roles, and ACLs, scripting provides the automation and precision needed for complex scenarios, integrations, and mass updates. Two crucial GlideRecord classes come into play when dealing with access control in scripts.

GlideRecord vs. GlideRecordSecure: A Critical Distinction

This is a foundational concept and a very popular interview question. Understanding the difference between GlideRecord and GlideRecordSecure is not just about functionality; it’s about security implications.

  • GlideRecord:
    • Does NOT automatically enforce ACLs.
    • When you use GlideRecord to query, insert, update, or delete records, it bypasses all ACLs unless you explicitly check them using methods like canCreate(), canRead(), canWrite(), or canDelete().
    • When to use: Primarily for backend scripts (Business Rules, Script Includes) where you need to perform actions with elevated privileges (e.g., an Admin-level script needs to update a record regardless of the current user’s ACLs) or for background scripts where you have explicitly managed the permissions logic.
    • Security Note: Use with extreme caution. If you use GlideRecord in a UI Action or Client Callable Script Include without explicit permission checks, you could inadvertently expose or allow modification of sensitive data.
  • GlideRecordSecure:
    • AUTOMATICALLY enforces ACLs for the currently logged-in user.
    • Every query, insert, update, or delete operation performed with GlideRecordSecure respects the ACLs that apply to the user running the script.
    • When to use: Any time you want to interact with data while respecting the current user’s permissions. This is the safer default choice for most custom logic, especially anything that could be triggered by a non-admin user.
    • Benefit: Reduces the risk of security vulnerabilities by inherently applying the platform’s access control.

Interview Relevance: “When would you use GlideRecordSecure over GlideRecord?” The answer is almost always: “When you want to ensure ACLs are respected for the current user, especially in client-facing or less privileged server-side scripts, to prevent security breaches.”

Practical Scripting Examples Revisited

We’ve already seen examples for creating users, groups, and assigning roles via script. These scripts are typically executed in a context where elevated privileges are either assumed (like a background script run by an admin) or explicitly handled by the wrapper (like an HR onboarding integration).

For instance, an HR onboarding workflow might trigger a script to create a new user, add them to specific groups (e.g., “All Employees”, “IT General”), and assign base roles. These operations often require system-level access and are appropriately handled by `GlideRecord` in a trusted server-side context (like a workflow or Flow Designer action that runs as ‘System’).

Advanced Access Control Concepts

Beyond the core components, ServiceNow offers additional features to manage access in more dynamic and nuanced ways.

User Delegation: Sharing the Workload

Life happens! People go on vacation, take sick leave, or are simply unavailable. User delegation in ServiceNow provides a mechanism to allow one user to temporarily act on behalf of another.

  • What it means: A delegated user gets permissions to perform tasks and access resources that are normally available to the original user. This ensures business continuity.
  • Real-world scenario: An IT manager going on holiday can delegate their approval tasks to a team lead. This way, critical approvals (like for new software requests or change requests) don’t get stuck waiting.
  • How to configure: The original user (or an admin) can go to their user account record, scroll down, and click the “Delegates” related list. Here, you can define:
    • Delegate: The person who will act on your behalf.
    • Start Date & End Date: The period of delegation.
    • Permissions: What specifically is being delegated:
      • Assignments
      • Notifications
      • Approvals

Delegation is a humane and practical feature, preventing bottlenecks and keeping workflows flowing even when key personnel are out of office.

Impersonation: Stepping into Their Shoes for Testing

Impersonation is an administrator’s best friend for testing. It allows an administrator (or anyone with the admin role) to temporarily log in as another user.

  • Purpose: The primary reason for impersonation is testing. If you’ve just made changes to ACLs, UI Policies, Client Scripts, or even a new portal page, you need to verify that a non-admin user sees and interacts with the platform exactly as intended.
  • How it works: When you impersonate a user, your session temporarily takes on their identity and permissions. You see what they see, and you can only do what they can do.
  • Why it’s essential: You can’t truly test access control without it. It’s the most reliable way to confirm that your ACLs, roles, and conditions are working as expected for different user types.

Always remember to switch back to your admin user when you’re done testing! There’s nothing worse than forgetting you’re impersonating a user and then accidentally making an administrative change with limited privileges.

Best Practices for Robust Access Control

Implementing access control isn’t a one-time setup; it’s an ongoing discipline. Adhering to best practices ensures your ServiceNow instance remains secure, manageable, and performant.

Role-Based Access Control (RBAC): The Gold Standard

We touched on this earlier, but it bears repeating and expanding:

  • Assign roles to groups, not directly to users. This is the cornerstone of RBAC. It simplifies management, improves auditability, and streamlines onboarding/offboarding processes.
  • Keep roles atomic and focused. Each role should grant a specific set of permissions related to a function or capability. Avoid creating “super roles” that grant excessive, unrelated access.
  • Minimize the number of roles. While keeping roles atomic, also try to avoid role sprawl. Consolidate where sensible to keep your role inventory manageable.

Principle of Least Privilege (PoLP)

This is a fundamental security concept: Grant users only the minimum access necessary to perform their job functions. Nothing more.

  • Avoid ‘admin’ role proliferation. The admin role is extremely powerful. It should be granted to a very small, trusted group of individuals and only when absolutely necessary. Regularly audit who has the admin role.
  • Start with restrictive ACLs. It’s generally safer to start by denying all access and then explicitly granting it, rather than granting all and then denying specific bits. This ensures no inadvertent access.

Regular Audits and Review

Access control isn’t a “set it and forget it” task.

  • Periodically review user, group, and role assignments. Check for dormant accounts, users with roles they no longer need, or groups that have become obsolete.
  • Audit ACLs. Especially after major releases or custom application deployments, review your ACLs to ensure they are still relevant and not inadvertently creating security gaps.

Documentation is Your Friend

Document your access control strategy. What roles exist? What permissions do they grant? Which groups have which roles? What are your key ACLs for critical tables? Good documentation is invaluable for troubleshooting, onboarding new administrators, and maintaining consistency.

Test, Test, Test!

Always test your access control changes thoroughly. Impersonation is your go-to tool here. Never assume an ACL or role change will work as expected without verifying it as a non-admin user.

Troubleshooting Common Access Control Issues

Even with the best practices, you’ll inevitably run into scenarios where a user can’t see something they should, or can see something they shouldn’t. Here’s a quick troubleshooting guide:

“Why can’t this user see this record/field?”

  1. Check Roles: Does the user have the necessary role(s) to access the table or field?
    • Is the role assigned directly to the user (less ideal) or, preferably, to a group the user is a member of?
    • Use gs.getUser().hasRole('role_name') in a background script (impersonating the user) to quickly verify.
  2. Check Group Membership: If roles are assigned to groups, is the user actually a member of the required group?
    • Use gs.getUser().isMemberOf('group_name') to verify.
  3. ACL Evaluation (Table first, then Field):
    • Table ACLs: Check the read ACLs for the table itself (e.g., incident.none). If the user fails here, they won’t see any records from that table.
    • Field ACLs: If table access is granted, then check the read ACLs for the specific field. If the field is blank or missing, a field-level ACL might be the culprit.
    • Debug Security: Turn on “Debug Security” (type “Debug Security” in the Filter Navigator and enable it). This will show you exactly which ACLs are being evaluated and whether they passed or failed, along with the conditions and roles. This is an absolute lifesaver for ACL troubleshooting!
  4. Conditions/Scripts on ACLs: Are there any conditions or scripts on the ACL that the user isn’t meeting? (e.g., “Active is true”, or a script that checks a custom field).
  5. Caching: Sometimes, especially after role changes, caches can cause issues. A quick cache.do (as admin) can often resolve phantom access problems, but use sparingly in production.

“My script isn’t working as expected with permissions.”

  1. GlideRecord vs. GlideRecordSecure: Is your script using the correct class? If you want ACLs to be respected, you MUST use GlideRecordSecure or explicitly check permissions with canRead(), etc., when using GlideRecord.
  2. Impersonate for Script Testing: Run your background script or test your workflow while impersonating the user whose permissions you are trying to simulate. This ensures your script logic and ACLs are evaluated correctly.

Conclusion

Access control in ServiceNow is more than just a technical feature; it’s a strategic imperative for data integrity, regulatory compliance, and user experience. By diligently managing users, groups, and roles, and by mastering the intricacies of ACLs, you can build a secure, efficient, and well-governed ServiceNow instance.

Remember the golden rules: assign roles to groups, practice the principle of least privilege, and always test your changes. Embrace tools like impersonation and Debug Security, and you’ll be well-equipped to navigate the complex world of ServiceNow security. A robust access control framework isn’t just about preventing bad things from happening; it’s about empowering your users to do their jobs effectively and securely, fostering trust in the platform, and ultimately, contributing to the success of your organization.

Keep learning, keep securing, and keep making your ServiceNow instance the best it can be!

Scroll to Top