Understanding Users, Groups, and Roles: The Building Blocks of Security

At the heart of any robust security model are users, groups, and roles. Think of them as the identity, team, and permission sets that define who can do what in your ServiceNow environment.

Users and Groups: Who’s Who in ServiceNow?

Every individual interacting with your ServiceNow instance is represented by a user record. These records are stored in the sys_user table. It’s the central repository for all your employees, contractors, and even integration accounts. Each user has a unique ID, username, email, and other profile details.

Groups, on the other hand, are collections of users. They’re designed to simplify management and reflect organizational structures or functional teams. For instance, you might have an “IT Support” group, a “HR Team” group, or a “Finance Approvers” group. The definition of these groups themselves resides in the sys_user_group table. The actual membership – linking a specific user to a specific group – is managed in the sys_user_grmember table. It’s a many-to-many relationship: a user can belong to multiple groups, and a group can have multiple users.

The Power of Group-Based Permissions: A Best Practice

When it comes to assigning permissions (roles) within ServiceNow, you have a choice: assign them directly to individual users or to groups. While assigning roles directly to users is technically possible, it is almost universally considered poor practice. Why?

The best practice, by far, is to assign roles to groups. Here’s why this approach shines:

• Scalability: Imagine a department with 50 people needing the same access. Instead of assigning 50 individual roles, you assign the role once to their department group. When a new person joins, you simply add them to the group, and they inherit all necessary roles automatically.
• Maintainability: If a role’s permissions need to change for a whole team, you modify the role on the group once, and it propagates to all members. No need to update 50 individual user records.
• Streamlined Offboarding: This is a huge one for security! When an employee leaves the organization, you simply remove them from their groups. As soon as they are removed from the groups, all associated roles are automatically revoked. This prevents orphaned permissions and ensures former employees no longer have access – a critical security measure.
• Consistency: Ensures everyone in a specific function or team has the same baseline access, reducing errors and inconsistencies.

Interview Relevance: “Can you add permissions to users and groups? Which is the best practice?” is a very common question. Your answer should strongly advocate for group-based role assignment and explain the benefits like scalability and offboarding efficiency.

Scripting User and Group Management: Efficiency at Your Fingertips

While manual creation and management of users and groups are fine for small-scale operations, larger organizations often require automation. This is where scripting with ServiceNow’s server-side API, GlideRecord, becomes indispensable.

Creating User Accounts Programmatically

Need to onboard a batch of new users from an HR system? A script can do it much faster and with fewer errors than manual entry. Here’s how you’d create a basic user account:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new, empty record for insertion
userGr.user_name = 'jdoe'; // Unique login name
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.active = true; // Set user as active by default
var newUserSysId = userGr.insert(); // Inserts the record and returns its sys_id

if (newUserSysId) {
    gs.info('User jdoe created successfully with Sys_ID: ' + newUserSysId);
} else {
    gs.error('Failed to create user jdoe.');
}

Explanation:

• new GlideRecord('sys_user'): Instantiates a GlideRecord object for the User table.
• initialize(): This is crucial for creating new records. It sets up the GlideRecord object to hold new data.
• userGr.fieldName = 'value': We assign values to the fields of the new record. Note that username in the reference is usually user_name in ServiceNow tables. It’s always good practice to verify field names from the dictionary.
• insert(): Commits the new record to the database. It returns the sys_id of the newly created record on success.

Troubleshooting: If a user fails to create, check for:

• Mandatory fields: Ensure all required fields (like user_name) have a value.
• Duplicate user_name: Usernames must be unique.
• Permissions: Ensure the script is run by a user with sufficient privileges (like Security Admin or user_admin).

Creating Groups with a Script

Similarly, creating groups can be automated:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'New Testing Group'; // The display name of the group
newGr.description = 'Group for testing purposes.';
// To set a manager, you need the sys_id of the user.
// Let's assume '62826bf03710200044e0bfc8bcbe5df1' is a valid sys_id for a user.
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
newGr.email = 'new_testing_group@example.com';
var newGroupSysId = newGr.insert();

if (newGroupSysId) {
    gs.info('Group "New Testing Group" created successfully with Sys_ID: ' + newGroupSysId);
} else {
    gs.error('Failed to create group "New Testing Group".');
}

Explanation: This follows the same GlideRecord pattern. Notice that the manager field expects a sys_id, as it’s a reference field to the sys_user table.

Troubleshooting: Ensure the group name is unique and the manager’s sys_id is valid.

Adding Roles to Users and Groups via Script

This is where the concept of role assignment tables comes in. ServiceNow uses junction tables to link users/groups to roles:

• sys_user_has_role: Links users to roles.
• sys_group_has_role: Links groups to roles.

To assign a role, you create a record in the appropriate table, referencing the sys_id of the user/group and the sys_id of the role.

Adding a Role to a User (less recommended, but possible):

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
// Assuming '62826bf03710200044e0bfc8bcbe5df1' is the sys_id of the user
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1');
// Assuming '2831a114c611228501d4ea6c309d626d' is the sys_id of the role (e.g., itil role)
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d');
var roleUserSysId = userRole.insert();

if (roleUserSysId) {
    gs.info('Role assigned to user successfully: ' + roleUserSysId);
} else {
    gs.error('Failed to assign role to user.');
}

Adding a Role to a Group (the recommended approach):

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
// Assuming '477a05d153013010b846ddeeff7b1225' is the sys_id of the group
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225');
// Assuming '2831a114c611228501d4ea6c309d626d' is the sys_id of the role (e.g., itil role)
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d');
var roleGroupSysId = grpRole.insert();

if (roleGroupSysId) {
    gs.info('Role assigned to group successfully: ' + roleGroupSysId);
} else {
    gs.error('Failed to assign role to group.');
}

Troubleshooting: Always double-check the sys_ids for the user/group and the role. An invalid sys_id will prevent the record from being created.

Managing Group Members Programmatically

Adding and removing users from groups is another common task that can be automated, especially for large employee movements or regular synchronizations. This involves the sys_user_grmember table.

Adding a Group Member:

// Before adding, it's good practice to check if the membership already exists
var grMemCheck = new GlideRecord('sys_user_grmember');
grMemCheck.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // User's sys_id
grMemCheck.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Group's sys_id
grMemCheck.query();

if (!grMemCheck.next()) { // Only add if the membership does not exist
    var grMem = new GlideRecord('sys_user_grmember');
    grMem.initialize();
    grMem.user = '62826bf03710200044e0bfc8bcbe5df1';
    grMem.group = '477a05d153013010b846ddeeff7b1225';
    var newMembershipSysId = grMem.insert();

    if (newMembershipSysId) {
        gs.info('User added to group successfully: ' + newMembershipSysId);
    } else {
        gs.error('Failed to add user to group.');
    }
} else {
    gs.info('User is already a member of this group.');
}

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // User's sys_id
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Group's sys_id
grMem.query();

if (grMem.next()) { // Check if the record exists before trying to delete
    grMem.deleteRecord();
    gs.info('User successfully removed from group.');
} else {
    gs.warn('User was not found as a member of this group.');
}

Troubleshooting: Always verify sys_ids. When removing, ensure the query correctly identifies the specific membership record you intend to delete.

Delegation and Impersonation: Tools for Flexibility and Testing

The Security Admin role often interacts with features that allow users to temporarily act on behalf of others, either for business continuity or for testing purposes.

User Delegation: Keeping Workflows Flowing

Imagine a scenario where a key approver or task assignee goes on vacation or takes leave. Critical workflows could grind to a halt! This is where user delegation steps in. User delegation in ServiceNow means allowing one user to work on behalf of another user for specific tasks or notifications within the organization.

The delegated user gains permissions to perform tasks and access resources that are normally available to the original user, but only for the specific items delegated (e.g., approvals, tasks, notifications) and within a defined timeframe.

Real-world example: An IT manager going on a two-week holiday can delegate their approval tasks for new software requests to a team lead. This ensures that no requests get stuck waiting for an approval that can’t happen.

To configure delegation, an original user (or an admin on their behalf) navigates to their user account profile, scrolls down, and clicks on the “Delegates” related list. Here, they can:

• Specify the “Delegate” (the user who will act on their behalf).
• Set a “Start Date” and “End Date” for the delegation period.
• Grant specific permissions for:
  • Approvals: The delegate can approve/reject items.
  • Assignments: The delegate can take over tasks assigned to the original user.
  • Notifications: The delegate receives notifications meant for the original user.
  • Meeting Invitations: (Less common, but possible).

This feature is vital for maintaining business continuity and operational efficiency, especially in organizations with frequent employee travel or leave.

Impersonation: Stepping into Another’s Shoes (for Testing!)

Impersonation is a powerful administrative tool that allows a user (typically an administrator or developer with the appropriate role) to temporarily log in as another user without knowing their password. The primary purpose of impersonation is testing.

When you impersonate a user, you experience the ServiceNow instance exactly as they would: seeing the same UI, forms, lists, and data based on their roles and ACLs. This is invaluable for:

• User Acceptance Testing (UAT): Verifying that new features or customizations work correctly for specific user groups.
• Troubleshooting: Diagnosing access issues, UI problems, or workflow behavior experienced by a particular user.
• Security Validation: Ensuring that ACLs and roles are correctly applied and users only see what they are supposed to see.

To impersonate, an admin simply clicks on their user name in the top right corner of the ServiceNow UI and selects “Impersonate User.” They then search for and select the user they wish to impersonate. Once done, a banner typically appears at the top of the screen indicating who they are currently impersonating. It’s crucial to remember to “End Impersonation” when testing is complete to return to your own administrative session.

Caution: Impersonation should only be used for legitimate testing and troubleshooting purposes, and never for malicious or unauthorized actions. Proper auditing is in place to track who impersonated whom and when.

Special User Types: Web Services Users

Not every “user” in ServiceNow is a human logging in via a web browser. Sometimes, external systems need to communicate with your ServiceNow instance to create, read, update, or delete records. This is where a web services user comes into play.

A web services user is an account specifically configured to grant access to a third-party application (via APIs like REST or SOAP) to connect to ServiceNow. The key characteristics are:

• Non-Interactive Login: These users cannot log in to the ServiceNow user interface like a typical human user. Their access is strictly programmatic.
• Limited Permissions: They are usually granted only the specific roles and ACLs necessary for their integration tasks, adhering to the principle of least privilege. For example, a web services user for an HR integration might only have permission to create user records or update HR profiles.
• Security: Using dedicated web services users enhances security by isolating integration access and making it easy to revoke access if an external system is decommissioned or compromised, without affecting human user accounts.

Real-world example: An external monitoring tool might use a web services user to create incident records in ServiceNow when it detects an outage. An HR system might use one to synchronize employee data into the sys_user table.

Current User Context: Scripting for the Active Session

When writing client-side or server-side scripts, you often need information about the currently logged-in user. ServiceNow provides convenient global objects for this.

Client-Side User ID

On the client side (e.g., in Client Scripts, UI Policies), you can access the current user’s system ID using:

g_user.userID; // Returns the sys_id of the current logged-in user, e.g., '6816f79cc0a8016401c5a33be04be441'

The g_user object provides several useful properties about the current user for client-side scripting, including their name, roles, and more.

Server-Side User ID

On the server side (e.g., in Business Rules, Script Includes, Workflow Scripts), you get the current user’s system ID with:

gs.getUserID(); // Returns the sys_id of the current logged-in user

The gs (GlideSystem) object is your go-to for server-side utilities and information about the current session and environment.

Interview Relevance: Differentiating between g_user and gs and knowing when to use each is a fundamental developer question.

Checking Group Membership

A common server-side requirement is to check if the current user belongs to a specific group. This is easy with gs.getUser():

if (gs.getUser().isMemberOf('ITIL Users')) {
    gs.info('Current user is a member of the ITIL Users group.');
} else {
    gs.info('Current user is NOT a member of the ITIL Users group.');
}

This method returns true if the user is a member of the specified group (by name) and false otherwise. It’s incredibly useful for controlling logic in business rules, script includes, or even within ACLs.

Access Control Demystified: The Heart of Security

If roles define what a user *can* generally do, then Access Control Lists (ACLs) define *who can access what data and functionality* at a granular level. ACLs are the gatekeepers of your ServiceNow data.

The Security Admin Role: Your Key to ACLs

To create, modify, or delete Access Control records (ACLs), you absolutely need the security_admin role. This is a critical security measure. By default, even administrators (admin role) cannot directly modify ACLs without first elevating their privileges to security_admin.

When an admin needs to work on ACLs, they click on their username in the top right corner and select “Elevate Roles.” From the pop-up, they select “security_admin” and confirm. This temporarily grants them the necessary elevated privileges. This “elevate roles” mechanism is a strong security practice, ensuring that even full admins don’t accidentally (or maliciously) alter critical access controls without a conscious decision to do so.

Interview Relevance: “Which role is required to work on access control?” The answer is unequivocally security_admin, and knowing about role elevation will impress.

Automatic ACL Creation with New Tables

Whenever you create a new table in ServiceNow (e.g., via Table Creator or from Studio), a default set of four Access Control records is automatically generated for that table, provided the “Create access controls” checkbox is checked (which it is by default). These four ACLs typically grant basic read, write, create, and delete access to the admin role (or a specific role associated with the application scope).

If you uncheck that box during table creation, no default ACLs will be created, meaning your new table will be completely inaccessible to everyone until you manually create appropriate ACLs. This is an important consideration: while it offers more control, it also means more manual work and a potential security oversight if not handled carefully.

Troubleshooting: If users can’t see or interact with a newly created table, the first place to check is the ACLs. Either they weren’t created, or they are too restrictive for the user’s roles.

Beyond Core Security: UI/Data Policies and Attachments

The Security Admin role often touches upon configurations that, while not strictly ACLs, significantly impact data integrity and user experience in relation to security.

Controlling Attachments: A Quick Security Win

Attachments can sometimes pose security risks (e.g., malware, sensitive data). ServiceNow provides a simple way to control attachments on forms using dictionary attributes. To disable attachments on a particular form (or table globally), you can add the no_attachment attribute to the “Attributes” field of the table’s dictionary entry (specifically, the “Collection” field). This will hide the attachment icon, preventing users from adding or viewing attachments on records for that table.

Practical Use: For sensitive forms or tables where attachments are not permissible due to compliance or security concerns (e.g., a “GDPR Data Deletion Request” form where attachments might inadvertently reintroduce data).

Data Policies vs. UI Policies: Knowing the Difference

These two policy types are often confused but serve distinct purposes related to form behavior and data integrity. A Security Admin should understand their differences and when to use each.

What are Data Policies?

Data Policies are server-side rules that enforce data integrity by making fields mandatory, read-only, or hidden under specific conditions. Crucially, they work across all data sources – whether the data is entered via a form, an import set, a web service, or a script. This means data policies enforce rules consistently, regardless of how the data gets into the system. They operate at both the client-side (to provide immediate feedback on the form) and the server-side (to prevent non-compliant data from being saved to the database).

Example: A data policy ensuring that the “Short Description” field is always mandatory for Incident records, no matter if created via the UI, email inbound action, or API.

Converting UI Policies to Data Policies: When and Why?

You can, in many cases, convert a UI Policy into a Data Policy. If you open a UI Policy record, you’ll often find a UI Action button or link labeled “Convert to Data Policy.” This is useful when you initially created a UI Policy to control form behavior, but then realize the data integrity rule needs to be enforced system-wide, not just when a user interacts with the form. The conversion process will attempt to map the UI Policy’s conditions and actions into a Data Policy.

Why convert? To promote the rule from a client-side form behavior to a server-side, universally enforced data integrity rule.

When Conversion Isn’t Possible (or Advisable)

Not all UI Policies can or should be converted to Data Policies. There are specific scenarios where UI Policies excel, and Data Policies simply cannot replicate their functionality:

• Controlling Data Visibility (e.g., hiding a field): While Data Policies can make fields hidden, UI Policies offer more dynamic control, especially when visibility depends on complex client-side logic that doesn’t necessarily block data submission (e.g., hiding a section based on a user’s role on the client-side, without making the field unavailable for backend processes).
• Controlling Views: UI Policies can target specific views, altering the form layout or field behavior only for users viewing that particular form view. Data Policies apply irrespective of the view.
• Controlling Related Lists: UI Policies can hide or show related lists based on client-side conditions. Data Policies have no control over related lists.
• Controlling Client-Side Scripting: If your UI Policy relies on running client-side scripts for complex interactions (e.g., populating a field dynamically based on another, or showing a custom alert), this logic cannot be directly converted into a Data Policy, which is declarative rather than script-based in its core function.

Interview Relevance: “Which are all the cases where UI policy cannot be converted as data policy?” This question tests your understanding of their fundamental differences and scopes.

Troubleshooting Common Security Admin Issues

Even with best practices, you’ll encounter hiccups. Here are some common issues and how to approach them:

• User can’t see a field/record:
  • Check ACLs: Are there ACLs preventing read access at the table or field level? Are the user’s roles correctly listed in the ACL? Use “Security Debugger” (requires security_admin) to trace ACL evaluations.
  • Check UI Policies/Client Scripts: Is something hiding the field on the form?
  • Check Query Business Rules: Is a Business Rule filtering records before they’re displayed?
  • Elevate roles: Ensure you are impersonating the user and have elevated to security_admin if modifying ACLs.
• User can see, but can’t edit:
  • Check write ACLs: Similar to read, but for write access.
  • Check Data Policies/UI Policies: Is a field being made read-only by a policy?
  • Workflow/State restrictions: Is the record in a state where editing is prohibited?
• Role assignment not working:
  • Correct Table: Are you adding to sys_user_has_role for users or sys_group_has_role for groups?
  • Valid Sys_IDs: Are the sys_ids for the user/group and role correct?
  • Cache: Sometimes role changes take a moment to reflect. Clear instance cache (cache.do) and try again.

Interview Corner: Acing Security Admin Questions

Beyond the specific questions covered above, a Security Admin interview might also probe your understanding of:

• Principle of Least Privilege: Always grant the minimum necessary access required for a user or system to perform its function.
• Role Hierarchy and Inheritance: How roles can inherit other roles.
• Contextual Security: Understanding how ServiceNow evaluates ACLs based on specific conditions.
• Security Best Practices: Beyond group-based roles, consider things like regular security audits, strong password policies, and multi-factor authentication.
• Difference between ‘admin’ and ‘security_admin’ roles: ‘admin’ is for general platform administration, while ‘security_admin’ is specifically for ACLs and other critical security settings.

Conclusion: Empowering Your ServiceNow Security Posture

The Security Admin role is foundational to maintaining a secure, efficient, and compliant ServiceNow environment. From managing users and groups to wielding the power of scripting for automation, understanding delegation for business continuity, and mastering Access Control Lists, the responsibilities are diverse and impactful.

By adhering to best practices like group-based role assignments and leveraging the tools ServiceNow provides, you can build a robust security framework that protects your data, streamlines operations, and empowers your users with precisely the access they need – nothing more, nothing less. Keep learning, keep practicing, and remember: strong security isn’t just a feature; it’s a continuous commitment.