Top ACL Interview Questions & Answers for Network Engineers

By /






Mastering ServiceNow ACLs and User Management: Top Interview Questions Unpacked



Mastering ServiceNow ACLs and User Management: Top Interview Questions Unpacked

Hey there, fellow ServiceNow enthusiast! Stepping into a technical interview, especially for a platform as powerful and nuanced as ServiceNow, can feel like navigating a maze. One area that consistently pops up, and rightly so, is Access Control Lists (ACLs) and the entire ecosystem of user and group management. Why? Because at the heart of any secure and functional enterprise platform lies robust access control. Mess this up, and you’re looking at potential security breaches, compliance nightmares, or simply a chaotic user experience.

This article isn’t just a list of questions and answers. Think of it as your personal mentor, walking you through the critical concepts, offering practical insights, real-world examples, and even a few troubleshooting tips. We’ll demystify the “why” behind best practices and equip you to not just answer questions, but to genuinely understand and apply these principles. So, let’s dive deep and get you ready to ace those top ServiceNow ACL and user management interview questions!

Understanding the Foundation: Users, Groups, and Roles

Before we even touch ACLs, it’s crucial to understand the building blocks: users, groups, and roles. These three elements form the bedrock upon which all access control is built in ServiceNow. Get these right, and your platform security is off to a flying start.

What’s the Best Practice for Adding Permissions? User vs. Group

This is a classic question, and for good reason. It immediately tells an interviewer if you understand scalable, maintainable security practices.

The Question: Can we add permissions (roles) directly to users and groups? Which is the best practice?

The Answer (and why it matters): Yes, absolutely, you can add roles directly to both users and groups. You can do this manually through the UI or programmatically using GlideRecord (more on that later!). However, the undisputed best practice, the gold standard, is to add permissions (roles) to groups, and then add users to those groups.

Why is this the best practice?

  • Scalability: Imagine managing permissions for a large organization with hundreds or thousands of users. If you grant roles directly to individual users, every time a user’s job role changes or a new team member joins, you’re manually updating multiple role records. With groups, you update the group’s roles once, and all members inherit them.
  • Maintainability: This is huge. Think about an employee leaving the organization. If their roles were granted directly, you’d have to meticulously go through their user record and remove each role. Miss one, and you have a lingering security risk. If roles are granted via groups, you simply remove the user from the relevant groups, and all their associated roles are automatically revoked. Clean, efficient, and less prone to error.
  • Consistency: Ensures that everyone in a particular team or department has the same set of necessary permissions, preventing discrepancies and simplifying auditing.
  • Simplicity: It’s easier to understand and manage “Marketing Team members get the ‘marketing_user’ role” than “John Doe gets marketing_user, Jane Smith gets marketing_user, etc.”

Interview Tip: When asked this, don’t just state the answer. Elaborate on the “why” with examples like employee onboarding/offboarding or team restructuring. This demonstrates a deeper understanding of real-world implications.

Under the Hood: Key User and Group Tables

Knowing the underlying table names shows you understand the platform’s architecture. Interviewers love this because it indicates you can debug, script, and truly understand where data lives.

  • What is the user table name? sys_user. This table holds all your user records – names, emails, usernames, passwords (hashed, of course!), and other user-specific data.
  • What is the group table name? sys_user_group. This table stores all your defined groups within ServiceNow.
  • Where do group members live? sys_user_grmember. This is a crucial many-to-many relationship table, linking users (`sys_user`) to groups (`sys_user_group`).
  • Where are roles assigned to users? sys_user_has_role. This table links users to the roles they directly possess.
  • Where are roles assigned to groups? sys_group_has_role. This table links groups to the roles granted to them, which are then inherited by their members.

Interview Tip: Not only list the table names but briefly explain their purpose. This shows comprehensive knowledge.

Scripting User and Group Management: Your Power Tools

ServiceNow is all about automation. Being able to script user and group operations using GlideRecord is a highly sought-after skill. It’s your key to bulk operations, integrations, and dynamic access management.

Creating User Accounts Programmatically

The Question: How to create a user account using a script?

The Answer: We use GlideRecord, ServiceNow’s API for database operations. It allows you to query, insert, update, and delete records.


var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record for insertion
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Note: ServiceNow often uses 'first_name', not 'firstname'
userGr.last_name = 'Doe';   // Note: ServiceNow often uses 'last_name', not 'lastName'
userGr.email = 'jdoe@example.com';
userGr.active = true; // Always good practice to set active status
userGr.insert(); // Inserts the new record into the sys_user table

gs.info("User jdoe created successfully!");

Practical Application: Think about integrating with an HR system. When a new employee is onboarded, an integration script could automatically create their ServiceNow user account. Or, for bulk user creation during a migration.

Troubleshooting Tip: If your script fails, check the field names carefully (e.g., `first_name` vs. `firstname`). Also, ensure any mandatory fields on the `sys_user` table are populated. Check your system logs for GlideRecord errors.

Crafting Groups with Code

The Question: How to create a group using a script?

The Answer: Similar to users, GlideRecord is your friend.


var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team'; // The display name of the group
// newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Optional: Manager's sys_id
newGr.email = 'testing@example.com';
newGr.description = 'Group for the testing department.';
newGr.insert();

gs.info("Group 'Testing Team' created successfully!");

Practical Application: Setting up project-specific groups dynamically based on project creation, or automating the creation of standard departmental groups.

Assigning Roles: The Right Way to Grant Access

The Question: How to add permissions (roles) to a user or group account using a script?

The Answer: Remember those `sys_user_has_role` and `sys_group_has_role` tables? This is where they come into play.

For a User (Direct Role Assignment – generally discouraged but possible):


// IMPORTANT: Replace with actual sys_ids for the user and the role
var userID = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user (e.g., John Doe)
var roleID = '2831a114c611228501d4ea6c309d626d'; // sys_id of the role (e.g., 'itil')

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', userID); // Link to the user
userRole.setValue('role', roleID); // Link to the role
userRole.insert();

gs.info("Role added to user successfully!");

For a Group (The Best Practice!):


// IMPORTANT: Replace with actual sys_ids for the group and the role
var groupID = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group (e.g., 'Testing Team')
var roleID = '2831a114c611228501d4ea6c309d626d'; // sys_id of the role (e.g., 'itil')

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', groupID); // Link to the group
grpRole.setValue('role', roleID);   // Link to the role
grpRole.insert();

gs.info("Role added to group successfully!");

Troubleshooting Tip: Always double-check your `sys_id` values! A common mistake is using an incorrect `sys_id` for the user, group, or role, leading to insert failures or assigning roles to the wrong entities. You can find sys_ids by right-clicking on the record header and selecting “Copy sys_id.”

Managing Group Membership: Adding and Removing Members

The Question: How to add and remove a group member from a group using a script?

The Answer: This involves manipulating the `sys_user_grmember` table.

Adding a Group Member:


// IMPORTANT: Replace with actual sys_ids for the user and the group
var userID = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
var groupID = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = userID;
grMem.group = groupID;
grMem.insert();

gs.info("User added to group successfully!");

Removing a Group Member:


// IMPORTANT: Replace with actual sys_ids for the user and the group
var userID = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
var groupID = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', userID);
grMem.addQuery('group', groupID);
grMem.query(); // Execute the query

if (grMem.next()) { // If a matching record is found
    grMem.deleteRecord(); // Delete that record
    gs.info("User removed from group successfully!");
} else {
    gs.warn("User was not found in the specified group.");
}

Real-world Use Case: Dynamic team changes. When an employee moves from one department to another, a script could automatically remove them from old groups and add them to new ones based on HR data updates. This maintains a clean and accurate user-group relationship without manual intervention.

Beyond Basic Permissions: Advanced User Concepts

User management isn’t just about who has access, but also about managing workflows and ensuring business continuity even when people are unavailable. These concepts demonstrate a practical understanding of how ServiceNow supports daily operations.

User Delegation: When You’re Out of Office

The Question: What exactly does user delegation mean in ServiceNow?

The Answer: User delegation means allowing one user to act on behalf of another user within the organization for specific tasks or processes. This is absolutely critical when the original user is unavailable – think vacations, sick leave, or even temporary project assignments.

Real-world Example: Imagine a manager, Sarah, is going on a two-week vacation. She has critical approval tasks that need to be actioned daily. Instead of these tasks piling up, Sarah can delegate her approval responsibilities to her colleague, Mark. While Sarah is away, Mark will receive and can act on approvals that would normally go to Sarah. This ensures that important workflows continue smoothly without interruption, preventing bottlenecks and delays.

How to set it up (UI path):

  1. Navigate to the original user’s profile (e.g., Sarah’s user record).
  2. Scroll down and click on the “Delegates” related list.
  3. Click “New” to create a new delegation record.
  4. Specify the “Delegate” (the person taking over, e.g., Mark).
  5. Set the “Start date” and “End date” for the delegation period.
  6. Select the permissions to delegate: Assignments, Notifications, Approvals, or even meeting invitations.

Interview Relevance: This question assesses your understanding of business continuity features within ServiceNow and how to manage workflow exceptions.

Web Services Users: The API Gatekeepers

The Question: What is a web services user in a user account?

The Answer: A “web services user” (often denoted by the “Web service access only” checkbox on the user record) is a specific type of user account designed exclusively for third-party applications or integrations to connect and interact with ServiceNow via its APIs (Application Programming Interfaces). These users are essentially non-human accounts.

Key Characteristics:

  • Cannot Log In Interactively: The most important distinction is that a web services user cannot log in to the ServiceNow instance through the standard user interface like a regular end-user or administrator. Their access is strictly programmatic.
  • Security: They are crucial for maintaining a secure integration posture. You can grant very specific roles and permissions to a web services user, ensuring that the connecting third-party application only has access to the data and operations it absolutely needs, following the principle of least privilege.
  • Auditability: Actions performed by integrations using these accounts are still logged, providing an audit trail for external system interactions.

Why they exist: Imagine you have an external monitoring tool that needs to create incident records in ServiceNow when an alert fires. You wouldn’t want that tool using a regular admin’s credentials, nor would you want it to have the ability to log in as a human. A web services user provides a secure, dedicated conduit for this machine-to-machine communication.

Impersonation: Your Debugging Superpower

The Question: What is impersonation?

The Answer: Impersonation in ServiceNow is a powerful administrative feature that allows a user with the appropriate role (typically admin or user_admin, with elevated security_admin for some actions) to temporarily “log in as” another user. While impersonating, the administrator experiences the ServiceNow instance exactly as the impersonated user would, seeing only the data and functionality that user is entitled to.

Purpose:

  • Testing: Essential for testing new features, changes, or access controls from the perspective of different user types (e.g., ITIL user, ESS user, manager).
  • Troubleshooting: If a user reports an issue (e.g., “I can’t see this record” or “I can’t submit this form”), an administrator can impersonate them to replicate the issue directly and diagnose the problem without needing their credentials.
  • User Support: Helps support teams understand and resolve user-specific interface or access problems.

Security Implications: While incredibly useful, impersonation must be used responsibly. It’s a high-privilege action and leaves an audit trail, which is important for security and compliance. Always ensure you revert to your own session after troubleshooting.

Checking Group Membership: `gs.getUser().isMemberOf()`

The Question: How to check if the current logged-in user is a member of a particular group using a script?

The Answer: ServiceNow provides a convenient server-side API for this, part of the Global Script (gs) object.


// Example 1: Check if the current user is a member of the 'ITIL Users' group
if (gs.getUser().isMemberOf('ITIL Users')) {
    gs.info("Current user is a member of ITIL Users group.");
    // Perform actions specific to ITIL users
} else {
    gs.info("Current user is NOT a member of ITIL Users group.");
    // Perform actions for non-ITIL users
}

// Example 2: You can also pass the sys_id of the group
var itilGroupID = '477a05d153013010b846ddeeff7b1225'; // Replace with actual sys_id
if (gs.getUser().isMemberOf(itilGroupID)) {
    gs.info("Current user is a member of the specified group by sys_id.");
}

Practical Use: This function is invaluable in Business Rules, Script Includes, Workflow Activities, and UI Actions where you need to dynamically control logic based on a user’s group membership. For instance, a Business Rule might prevent a record from being updated unless the current user is part of the “Managers” group. Or, a UI Action might only display if the user is in the “Finance” team.

Interview Tip: This shows you’re familiar with the global server-side `gs` object and its powerful utility methods, which is a common requirement for scripting in ServiceNow.

Diving Deep into Access Control (ACLs)

Now for the main event: Access Control Lists (ACLs). This is where the rubber meets the road for security. ACLs determine who can access what data at a very granular level. A deep understanding here is non-negotiable for any serious ServiceNow professional.

The Gatekeeper Role: `security_admin`

The Question: Which role is required to work on access control (ACLs)?

The Answer: The security_admin role is required. This is a special, elevated role in ServiceNow. By default, even users with the `admin` role cannot create or modify ACLs directly. They must first elevate their privileges to `security_admin` for the current session.

Why the Elevation? This “elevation of privilege” mechanism is a critical security measure. It prevents casual or accidental changes to fundamental security rules. It ensures that changes to ACLs are intentional and performed by someone who explicitly understands the implications of their actions. It adds an extra layer of protection against unauthorized access.

ACL Creation: Default Behavior for New Tables

The Question: Whenever we create a table, how many access controls (ACLs) get created by default?

The Answer: When you create a new table in ServiceNow (e.g., via Table Creator or by extending an existing table), if the “Create access controls” checkbox is checked (which it is by default), four ACLs are automatically created for that table:

  1. Create: Allows users to create new records in the table.
  2. Read: Allows users to read (view) records in the table.
  3. Write: Allows users to update (modify) records in the table.
  4. Delete: Allows users to delete records from the table.

These default ACLs typically grant access to the `admin` role or a specific role defined during table creation. If you uncheck that box during table creation, no default ACLs will be created, meaning no one (except perhaps system administrators with elevated privileges) will have access to records in that table until you create ACLs manually.

Interview Relevance: This question tests your knowledge of platform defaults and best practices around initial table security. It highlights that you understand the immediate security implications of creating new data structures.

When and How Many ACLs? The Granular Control

ACLs aren’t just for tables; they provide granular control at multiple levels. Understanding this hierarchy is key.

  • Record ACLs: These apply to an entire record (row) in a table. They control who can `create`, `read`, `write`, or `delete` any record. They are defined on the table name itself (e.g., `incident`).
  • Field ACLs: These apply to specific fields (columns) within a table. They control who can `read`, `write`, or `create` a particular field. They are defined on `table.field_name` (e.g., `incident.short_description`).

ACL Evaluation Order: This is critical for troubleshooting! ACLs are evaluated from most specific to most general. For a given operation (e.g., read):

  1. Field ACLs (most specific): ServiceNow first checks field-level ACLs. For instance, `incident.short_description`.
  2. Record ACLs (general): If no field-level ACL applies, or if the field-level ACL allows access, ServiceNow then checks the table-level ACL (e.g., `incident`).
  3. Wildcard ACLs: If specific field or table ACLs don’t explicitly grant access, ServiceNow then looks at wildcard ACLs (e.g., `incident.*` for any field on the incident table, or `*.short_description` for that field on any table, or even `*.*` for any field on any table – these are very general and rarely used without specific requirements).

Important Rule: For a user to access a field, both the field ACL (if one exists) AND the record ACL must evaluate to true. If a record ACL denies access, no field ACL, however permissive, can override it. Think of it as opening a safe (record ACL) before you can get to the specific compartments (field ACLs).

Practical Example: Restricting a Field:

Let’s say you want anyone with the `itil` role to read Incident records, but only users with the `itil_admin` role should be able to modify the “State” field of an Incident.

  1. Incident Read ACL (`incident` operation `read`): Requires `itil` role. This allows `itil` users to view the entire incident record.
  2. Incident State Write ACL (`incident.state` operation `write`): Requires `itil_admin` role. This overrides the default write access for the `state` field, ensuring only `itil_admin` can change it. Other `itil` users can still see the field (due to the record read ACL) but cannot change it.

Troubleshooting ACLs: When Access Goes Awry

ACLs can be tricky. Here’s how to approach common access issues:

  • ACL Debugger: Your best friend! Enable the “Debug Security” option (System Security -> Debugging). This will show you exactly which ACLs are being evaluated and why they are passing or failing as you navigate the UI. It’s an indispensable tool for understanding and fixing access problems.
  • Check Roles: Is the user missing a required role? Use `gs.hasRole()` or `gs.getUser().hasRole()` in background scripts to quickly check a user’s role status.
  • Hierarchy and Order: Remember the specific-to-general rule. A field ACL needs a record ACL to pass first. Also, a “higher” (more specific) ACL can deny access even if a “lower” (more general) one would allow it.
  • Conditions and Scripts: ACLs can have conditions and script fields. Check these for any logic that might be unexpectedly preventing access. A complex script might be returning `false` incorrectly.
  • Wildcard Conflicts: Be cautious with wildcard ACLs (e.g., `*.*`). They can sometimes unintentionally grant or deny access more broadly than intended.
  • Elevated Privileges: Remember `security_admin`! If you’re modifying ACLs and they’re not taking effect, ensure you’ve properly elevated your role.

Beyond ACLs: Other Ways to Control Form Behavior

While ACLs control data access, there are other powerful mechanisms in ServiceNow to control how fields behave on forms – making them mandatory, read-only, or hidden. Interviewers often ask about this to gauge your comprehensive understanding of form configuration.

Making Fields Mandatory or Read-Only: A Multi-faceted Approach

The Question: In how many ways can we make a field mandatory or read-only?

The Answer: There are five primary ways, each with its own use case and order of precedence:

  1. Dictionary Properties:

    • What it is: The most fundamental and server-side way to define a field’s behavior. Found directly on the Dictionary Entry for the field.
    • When to use: When a field should *always* be mandatory or read-only across the entire platform, regardless of the table or how it’s accessed (UI, script, integration).
    • Example: Making the “Short description” field on the Task table permanently mandatory for all tasks.
    • Precedence: High baseline enforcement.
  2. Dictionary Overrides:

    • What it is: Allows you to override dictionary properties for a field when it’s used on a *specific extended table*. Still server-side.
    • When to use: When you want a field to behave differently on a child table than it does on its parent table (e.g., the “Description” field is optional on Task but mandatory on Incident).
    • Example: Making the “Description” field mandatory only for Incident records, even though it’s optional on the Task table it extends.
    • Precedence: Higher than Dictionary Properties for the specific child table.
  3. UI Policies:

    • What it is: Client-side logic that dynamically modifies form fields based on conditions. You define conditions and then specify actions (e.g., make mandatory, read-only, visible).
    • When to use: For dynamic, real-time changes on the form based on user input or other field values. It only applies to the UI.
    • Example: Making the “Assignment group” field mandatory only when the “State” field is set to “In Progress.”
    • Precedence: Executes on the client-side, generally after server-side rules are applied. Can be overridden by client scripts.
  4. Data Policies:

    • What it is: Server-side enforcement of field behavior, similar to UI Policies but much stronger. They apply to all data input, regardless of how it’s entered (UI, import, API, script).
    • When to use: When you need to enforce data integrity rules across all input methods, not just the UI. Often paired with UI Policies (where the UI Policy enforces on the form, and the Data Policy enforces on the server).
    • Example: Ensuring that a “Category” field is mandatory whenever an incident is created or updated, regardless if it’s done via the form, a script, or an integration.
    • Precedence: Server-side enforcement, overrides UI Policies if there’s a conflict for mandatory/read-only behavior.
  5. Client Scripts (`g_form.setMandatory()` / `g_form.setReadOnly()`):

    • What it is: Custom client-side JavaScript code that runs in the browser. You can use the `g_form` API to manipulate fields.
    • When to use: For highly complex or very specific dynamic scenarios that UI Policies can’t handle. Generally, prefer UI Policies if they can achieve the desired outcome, as they are easier to maintain.
    • Example: Making a custom field mandatory based on a calculation or a specific interaction not covered by simple conditions.
    • Precedence: Highest on the client-side. Can override UI Policies.

Interview Tip: Explain the purpose and execution context (client-side vs. server-side) for each method. Demonstrate that you understand the hierarchy and when to use one over the other. For example, explain why a Data Policy is stronger than a UI Policy for mandatory enforcement.

Conclusion: Your Path to ACL and User Management Mastery

Navigating ServiceNow ACLs and user management can seem daunting, but by breaking it down into these core concepts and understanding the “why” behind each, you’re not just memorizing answers; you’re building a foundation of true expertise. From the fundamental best practice of assigning roles to groups, to the intricacies of GlideRecord scripting, and the critical role of ACLs in securing your data, each piece of knowledge strengthens your overall command of the platform.

Remember, the goal in an interview isn’t just to parrot definitions. It’s to demonstrate a practical, hands-on understanding. Use real-world examples, talk about the implications of your choices, and be ready to troubleshoot. Practice those GlideRecord scripts, experiment with ACLs in a development instance (with `security_admin` elevated!), and get comfortable with the ACL Debugger.

With this detailed guide, you’re now much better equipped to confidently tackle those top ServiceNow ACL and user management interview questions. Go forth and conquer!


Scroll to Top