ServiceNow Roles vs Groups: The Complete Access Management Guide

The fundamental difference

The single most important thing to understand about Roles and Groups:

• Roles control what a user can do — ACLs reference roles. A user with a role passes the role check on any ACL that lists that role.
• Groups organise who handles work — incidents are assigned to groups, approvals route through groups, CMDB has group ownership. Groups do not directly grant access to records.

ACLs never check group membership directly. They only check roles. A user in the "Network Team" group cannot see network incidents because they are in the group — they can see them because the group has the itil role, which they inherit.

This distinction matters because it determines where you need to make changes when access is wrong. If a user cannot see records they should see, check their roles — not their group membership. If records are not being assigned to the right team, check their group membership.

What is a Role?

A Role is a named permission set stored in the sys_user_role table. Roles are referenced by:

• ACLs — "User must have this role to read/write/create/delete"
• Business Rules — gs.hasRole('itil')
• Scripts — gs.hasRole('catalog_admin')
• UI Actions — visibility conditions using role checks
• Service Catalog — catalog items visible only to certain roles
• Approval rules — approvers must have specific roles

Roles are either assigned directly to a user, or inherited from group membership. Either way, the user "has" the role from the platform's perspective — there is no difference in how ACLs evaluate the role check.

Role inheritance — how roles include other roles

Roles can include other roles. When a user has Role A, and Role A includes Role B, the user effectively has both Role A and Role B without Role B being explicitly assigned.

// Role hierarchy example:
// itil_admin includes: itil
// If user has itil_admin, they also have itil
// ACLs that require itil are satisfied by users with itil_admin

// Check in Scripts - Background:
var gr = new GlideRecord('sys_user_role_contains');
gr.addQuery('role.name', 'itil_admin');
gr.query();
while (gr.next()) {
    gs.log('itil_admin includes: ' + gr.contains.name);
}

The admin role is the most extreme example — it includes virtually every other role in the system. Users with admin implicitly pass almost every role check on every ACL.

When building custom roles, be deliberate about role includes. A custom role that includes admin grants far more access than intended. Include only the specific roles that the custom role should encompass.

Key built-in roles

Role	What it grants	Typically assigned to
itil	Read/write on ITSM tables (incident, problem, change, task)	Service desk agents, IT staff
itil_admin	Admin-level ITSM access including configuration	ITSM team leads, process owners
admin	Full platform access — includes almost everything	System administrators only
catalog_admin	Create and manage service catalog items	Catalog managers
knowledge_admin	Manage knowledge base articles and categories	Knowledge managers
report_admin	Create and manage reports for all users	Reporting team
snc_internal	Basic platform access for ITSM consumers	End users/requestors
approver_user	Approve/reject approval requests	Managers, approvers

What is a Group?

A Group is an organisational container for users, stored in the sys_user_group table. Groups serve several purposes:

• Assignment — incidents, changes, and tasks are assigned to groups for team-level ownership
• Approval routing — approval rules route to "managers of" or "members of" specific groups
• CMDB ownership — CIs have an assignment group that indicates who manages them
• On-call schedules — on-call rotations are configured at the group level
• Role distribution — assigning roles to groups means every group member inherits those roles automatically

Groups and roles — how they connect

Groups have a Roles tab. Roles assigned to a group are inherited by every user who is a member of that group. This is the most common way roles are distributed in production environments — not by assigning roles directly to individual users, but by putting users in the right groups.

// Example:
// Group: Service Desk Team
// Group roles: itil, service_desk
// Users in this group: Agent A, Agent B, Agent C

// Result: Agent A, B, and C all have the itil role
// They can read and write incident records
// They do NOT have the itil_admin role
// They CANNOT modify ACLs or ITSM configuration

When a user is removed from a group, they lose all roles they inherited from that group — unless those roles are also assigned to them directly or via another group they are still in.

Three ways to assign roles to users

Method 1 — Directly on the user record

Navigate to the user record → Roles tab → Add role. Use for roles that should follow the user regardless of group membership — typically for individual exceptions or system accounts.

// View a user's directly-assigned roles:
var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('user', userSysId);
gr.addQuery('inherited', false); // Not inherited from a group
gr.query();
while (gr.next()) {
    gs.log(gr.role.name + ' (direct assignment)');
}

Method 2 — Via group membership (recommended for most cases)

Assign roles to the group, then add users to the group. Users inherit roles automatically. When access needs to change, update the group's roles or group membership — not individual user records. This is the scalable approach for teams.

Method 3 — Via role inheritance (programmatically)

Custom roles that include other roles distribute access through the role hierarchy. When you assign the parent role, the user gets all included roles automatically.

Checking roles in scripts

// Check if current user has a role
gs.hasRole('itil');               // Returns true/false
gs.hasRole('itil,catalog_admin'); // True if user has EITHER role

// Check for a specific user (not current user)
var userGr = GlideUser.getUserByID(userId);
userGr.hasRole('itil');

// Check if current user has any elevated/admin role
gs.hasRole('admin');

// Get all roles of current user
var roles = gs.getUser().getRoles();
gs.log('Roles: ' + roles);

// Check in an ACL script
answer = gs.hasRole('itil') || gs.hasRole('catalog_admin');

Checking group membership in scripts

ACLs do not check group membership directly, but scripts often need to. Use the sys_user_grmember table:

// Check if a specific user is in a specific group
function isUserInGroup(userId, groupId) {
    var gr = new GlideRecord('sys_user_grmember');
    gr.addEncodedQuery('user=' + userId + '^group=' + groupId);
    gr.query();
    return gr.next();
}

// Usage:
var inGroup = isUserInGroup(gs.getUserID(), current.assignment_group.toString());

// Check by group name instead of sys_id
function isUserInGroupByName(userId, groupName) {
    var gr = new GlideRecord('sys_user_grmember');
    gr.addEncodedQuery('user=' + userId + '^group.name=' + groupName);
    gr.query();
    return gr.next();
}

// Get all groups for the current user
var gr = new GlideRecord('sys_user_grmember');
gr.addQuery('user', gs.getUserID());
gr.query();
while (gr.next()) {
    gs.log('Member of group: ' + gr.group.getDisplayValue());
}

The isUserInGroup() function pattern is commonly used in ACL scripts to implement group-based access control — but remember the performance warning from the ACL guide: GlideRecord queries in ACL scripts run on every record access. Cache the result if performance is a concern.

Group types and sub-groups

Groups have a Type field that categorises them: IT, HR, Legal, etc. This is informational — it does not affect access control or assignment routing.

Groups support a parent group hierarchy. A group can have a parent group, creating an organisational tree. Group membership is not hierarchical by default — being in a child group does not make a user a member of the parent group. However, some ServiceNow features (like approval routing to "manager of group") traverse the hierarchy.

Common access management mistakes

Mistake 1 — Assigning admin to solve access problems

The quickest fix to an access problem is often "give them admin." The consequences: admin bypasses ACLs, allows destructive operations, enables access to sensitive data across the entire platform. Never assign admin to non-system-administrator users. Diagnose the actual missing role instead.

Mistake 2 — Not using groups for role distribution

Assigning roles directly to individual users creates a maintenance nightmare. When a team member joins, every role must be added manually. When they leave, every role must be removed manually. Roles assigned to groups are automatically gained and lost as users join and leave groups.

Mistake 3 — Checking group membership for access control instead of roles

ACL scripts that check group membership directly are less maintainable than role-based checks. If the team changes its group structure, the ACL script breaks. Use roles for access control, groups for work routing.

Mistake 4 — Not auditing role assignments periodically

Users accumulate roles over time — direct assignments from project access, temporary elevated roles that were never removed. Periodic role audits are an important security hygiene practice. Query sys_user_has_role for directly-assigned roles and review any that look unexpected.

Mistake 5 — Custom roles that include too much

A custom role created for "read-only access to ITSM" that includes itil gives write access as well. Always review which roles your custom role includes — the role hierarchy can grant more than you intended.

Related guides:

• ACLs complete guide — how roles are used in access control
• ACL Security Guide — advanced security patterns
• Debugging scripts — diagnosing access issues