Unraveling Automatic ACL Creation: A Deep Dive for ServiceNow Admins

In the intricate world of ServiceNow, managing user access and data security is paramount. Access Control Lists (ACLs) are the bedrock of this security framework, dictating who can see, create, read, update, or delete records and fields. While many administrators manually craft ACLs, there’s a fascinating aspect of their creation that often happens behind the scenes: automatic ACL generation. This article aims to demystify this process, exploring how and why ACLs are created without explicit manual intervention, and how this ties into broader security best practices within the platform.

The Genesis of Automatic ACLs: Table Creation and Beyond

The most prominent instance of automatic ACL creation occurs when you create a new table in ServiceNow. Imagine you’re designing a new application module, perhaps for tracking company assets or managing internal training programs. You define your data structure by creating a new table. At this very moment, the platform, by default, springs into action to lay down a foundational security layer for your new table.

The Default ACLs: A Four-Pillar Defense

When you create a table and the relevant checkbox is ticked (and it is by default!), ServiceNow automatically generates four Access Control Lists. These are not arbitrary; they serve as essential building blocks for securing your new data:

• Read ACL: This allows users to view records within the table.
• Write ACL: This permits users to modify existing records.
• Create ACL: This enables users to create new records.
• Delete ACL: This grants users the ability to remove records.

These defaults are designed to provide a basic level of access, often allowing users with broader roles (like the itil role) to interact with the new table. This is a crucial convenience, as it saves administrators from having to immediately secure every new table from scratch. However, it’s vital to remember that these are just defaults. For robust security, you’ll almost always need to customize and refine these ACLs to match your specific requirements.

The Role of Roles in Access Control

While ACLs define *what* is permitted, roles define *who* has the permissions. The automatic ACLs generated upon table creation are typically associated with common ServiceNow roles. This is where the concept of best practices in user and group management becomes critical. As highlighted in reference point 3:

“Yes, we can add roles to the users and groups manually and as well as with the script by using GlideRecord. The best practice is to add the permissions from group…so that whenever an employee leaves an organisation and if we remove that person from the group the roles will be removed automatically.”

This principle directly impacts how those automatically generated ACLs are utilized. If an ACL grants access to a specific role, and that role is assigned to a group, then all members of that group inherit the permissions granted by that ACL. When a user leaves the organization and is removed from the group, their access, governed by the group’s roles, is automatically revoked. This is a far more efficient and secure approach than managing permissions on a user-by-user basis.

Programmatic Access: Scripts and the `GlideRecord` Object

Beyond the table creation event, administrators often need to manage permissions programmatically. This is where scripting comes into play, particularly using the powerful GlideRecord object. Reference point 8 provides excellent examples of this:

Granting Permissions to Users via Script

When you grant a role to a user manually, a record is created in the sys_user_has_role table. You can replicate this process using a script:

    var userRole = new GlideRecord('sys_user_has_role');
    userRole.setValue('user', 'sys_id_of_the_user'); // Replace with actual user sys_id
    userRole.setValue('role', 'sys_id_of_the_role'); // Replace with actual role sys_id
    userRole.insert();
    

Explanation:

• We instantiate a GlideRecord object targeting the sys_user_has_role table. This table is the linchpin connecting users to their assigned roles.
• setValue('user', 'sys_id_of_the_user'); assigns the specified user to this role assignment. You’ll need the unique system ID (sys_id) of the user.
• setValue('role', 'sys_id_of_the_role'); links the specified role to this assignment. Again, the role’s sys_id is required.
• insert(); saves this new record, effectively granting the role to the user.

Granting Permissions to Groups via Script

Similarly, when you assign a role to a group, a record is created in the sys_group_has_role table. You can achieve this with a script:

    var grpRole = new GlideRecord('sys_group_has_role');
    grpRole.setValue('group', 'sys_id_of_the_group'); // Replace with actual group sys_id
    grpRole.setValue('role', 'sys_id_of_the_role'); // Replace with actual role sys_id
    grpRole.insert();
    

Explanation:

• We initialize a GlideRecord for the sys_group_has_role table, which manages the relationship between groups and roles.
• setValue('group', 'sys_id_of_the_group'); specifies the group that will receive the role.
• setValue('role', 'sys_id_of_the_role'); defines the role being assigned.
• insert(); commits the role assignment to the group.

Managing Group Membership: The Foundation for Role Inheritance

The power of group-based permissions, as advocated in the best practices, hinges on efficient group membership management. Scripts can automate adding and removing users from groups, which in turn influences their access based on group roles.

Adding a Group Member via Script

When you add a user to a group, a record is created in the sys_user_grmember table:

    var grMem = new GlideRecord('sys_user_grmember');
    grMem.user = 'sys_id_of_the_user'; // Replace with actual user sys_id
    grMem.group = 'sys_id_of_the_group'; // Replace with actual group sys_id
    grMem.insert();
    

Explanation:

• A GlideRecord is initiated for the sys_user_grmember table, which maps users to groups.
• The user and group fields are populated with the respective sys_ids.
• insert(); creates the membership record.

Removing a Group Member via Script

To remove a user from a group, you first need to find the specific membership record and then delete it:

    var grMem = new GlideRecord('sys_user_grmember');
    grMem.addQuery('user', 'sys_id_of_the_user'); // Replace with actual user sys_id
    grMem.addQuery('group', 'sys_id_of_the_group'); // Replace with actual group sys_id
    grMem.query();
    if (grMem.next()) {
        grMem.deleteRecord();
    }
    

Explanation:

• We query the sys_user_grmember table.
• addQuery('user', ...); and addQuery('group', ...); are used to pinpoint the exact membership record for the specified user and group.
• query(); executes the search.
• if (grMem.next()) { ... } checks if a matching record was found. It’s important to ensure a record exists before attempting to delete it.
• grMem.deleteRecord(); removes the membership record.

ACLs vs. UI Policies vs. Data Policies: A Clarification

It’s crucial to distinguish between Access Control Lists and other control mechanisms like UI Policies and Data Policies. While they all contribute to managing the user experience and data integrity, they operate at different levels.

Understanding UI Policies

UI Policies (reference point 58) are client-side scripts that control the behavior of form fields. They can make fields mandatory, read-only, visible, or hidden, and can even show related lists based on certain conditions.

• Global Checkbox (59): When checked, the UI Policy applies to all views. Unchecked, you specify the views.
• Reverse if False (60): If checked, the UI Policy’s actions are reversed when the condition is false. For example, a field made mandatory when true becomes optional when false.
• On Load Checkbox (61): If checked, the UI Policy runs as soon as the form loads. If unchecked, it triggers based on field changes or other events.
• Inherit Checkbox (62): If checked, the UI Policy is applied to child tables that extend the current table.
• Running Scripts in UI Policies (63): You can embed client-side scripts within UI Policies by enabling the “Run scripts” checkbox.
• Converting UI Policies to Data Policies (64, 65): UI Policies can often be converted to Data Policies, but this isn’t possible when controlling data visibility, views, related lists, or complex scripting that relies heavily on client-side interactions.

Understanding Data Policies

Data Policies (reference point 66), on the other hand, enforce mandatory fields, read-only states, and display properties across all data sources, including server-side operations and integrations. They are more robust for ensuring data integrity regardless of how the data is accessed.

The Crucial Difference: ACLs are About Authorization

While UI and Data Policies influence the user experience and enforce data rules, ACLs are fundamentally about authorization. They determine whether a user is *allowed* to perform an action at all. You could have a UI Policy that makes a field read-only, but if an ACL denies write access to the record, the user still won’t be able to update it, regardless of the UI Policy. Conversely, even if an ACL permits write access, a UI Policy could still restrict the user from seeing or interacting with a specific field on the form.

Reference Qualifiers: Refining Reference Fields

Reference qualifiers are a powerful tool for controlling the data presented in reference and list fields. They act as filters, ensuring that users select from a relevant subset of records. As outlined in reference point 48, there are three types:

• Simple Reference Qualifier: Uses a direct, fixed query (e.g., active=true). This is the most straightforward and is ideal for static filtering.
• Dynamic Reference Qualifier: Leverages “Dynamic Filter Options” defined in the system. These are more flexible as they can adapt to the current context, like values on the form. For example, showing only incidents assigned to the current user’s assignment group.
• Advanced Reference Qualifier (JavaScript): This is the most powerful, allowing custom JavaScript code to define complex filtering logic. You can combine multiple conditions, access other fields, and perform calculations to dynamically filter the referenced records. For example, javascript: 'assignment_group=' + current.assignment_group + '^priority<3'; (Note: The example in the reference used a hardcoded sys_id; a dynamic approach using current.assignment_group is more practical).

While reference qualifiers don't directly create ACLs, they are part of the broader security and data governance puzzle. By ensuring users can only select valid related records, they indirectly support data integrity and can simplify the design of more complex ACLs.

The Role of the Security Admin

It’s important to note that working with ACLs, especially advanced configurations and the creation/modification of security rules, often requires elevated privileges. As reference point 16 states, the security_admin role is generally required to work on access control.

This role grants comprehensive access to security configurations, allowing administrators to create, modify, and delete ACLs, roles, and other security-related configurations. It's a powerful role and should be assigned judiciously to prevent unintended security breaches.

Conclusion: A Layered Approach to Security

Automatic ACL creation, primarily during table generation, is a foundational feature in ServiceNow that provides an essential security baseline. However, it’s merely the starting point. True data security and access management are achieved through a layered approach:

• Leveraging automatic ACLs: Understanding what is created by default.
• Role-based access control (RBAC): Assigning permissions to roles and then assigning roles to groups.
• Scripting: Automating role and group membership management for efficiency and accuracy.
• UI Policies and Data Policies: Enhancing user experience and enforcing data integrity on forms and across the platform.
• Reference Qualifiers: Refining data selection in reference fields.
• Careful ACL design: Customizing ACLs to meet specific business requirements.

By understanding how ACLs are created automatically and how they interact with other security mechanisms and best practices, administrators can build more robust, scalable, and maintainable security frameworks within ServiceNow. This knowledge is not only critical for day-to-day administration but also a key differentiator in technical interviews.