Group

What It Is

Groups are named collections of users that serve as the primary mechanism for organizing people around work, responsibilities, and access permissions in ServiceNow. They solve the fundamental problem of how to assign tasks, route approvals, escalate issues, and control access at scale without having to manage individual users one by one. Every incident gets assigned to a group, every approval workflow routes through groups, and every access control rule typically references group membership rather than individual users.

Groups live in the core User Administration application as part of the foundational identity and access management layer of ServiceNow. They're stored in the sys_user_group table and connect to users through the many-to-many relationship table sys_user_grmember. This architecture allows users to belong to multiple groups simultaneously and groups to contain multiple users, which is essential for real-world organizational structures where people wear multiple hats and responsibilities overlap.

The group data model integrates deeply with ServiceNow's workflow engine, assignment rules, access control framework, and notification system. When you create an assignment rule that routes incidents based on category, it's looking up groups and their members. When you build an approval workflow that requires manager sign-off, it's traversing group hierarchies and manager relationships. When you configure access control lists (ACLs) to restrict who can see certain records, you're typically checking group membership rather than individual user permissions.

You cannot function without groups in any ServiceNow implementation that handles work distribution or access control. Try to assign incidents without assignment groups, and you'll have no systematic way to route work to the right teams. Attempt to build approval processes without groups, and you'll end up hardcoding individual user names that break every time someone changes roles. Try to manage access permissions without groups, and you'll create an unmaintainable mess of individual user ACL entries that becomes impossible to audit or update at scale.

Platform owners typically define the group structure and naming conventions, while admins handle day-to-day group creation and membership management. Developers rarely create groups directly but frequently reference them in scripts, assignment rules, and workflow logic. The relationship becomes critical during organizational changes—when teams restructure or merge, it's the admin who updates group memberships and hierarchies, but it's the platform owner who decides whether to create new groups or modify existing ones. Group management is one of those foundational tasks that touches every other ServiceNow feature, making it essential knowledge for anyone responsible for platform operations.

Where to Find and Configure It

Navigate to User Administration > Groups for the primary group management interface where you create, modify, and delete groups. Go to User Administration > Users and open any user record to see the Groups related list where you manage individual user memberships. Access System Definition > Tables and search for sys_user_group to see the underlying table structure and customize group fields if needed.

Check System Security > Access Control (ACL) to see groups referenced in security rules. Visit System Policy > Assignment > Assignment Rules to see groups used in automatic work routing. Look at Workflow > Workflow Editor to see groups in approval and notification activities. Groups appear in reference fields throughout ServiceNow—any field with type reference pointing to sys_user_group will show a group picker.

How It Works Step by Step

Groups function as lookup tables that ServiceNow queries whenever it needs to determine user relationships, assignment targets, or access permissions. When you assign a record to a group, ServiceNow doesn't immediately resolve that to individual users—instead, it stores the group reference and resolves membership dynamically when needed. This lazy evaluation means group membership changes immediately affect all records assigned to that group without requiring updates to those records.

The group resolution process involves multiple table lookups and inheritance rules. ServiceNow first checks direct group membership in sys_user_grmember, then applies any group hierarchy rules if parent-child relationships exist. The system also considers group managers, which are stored as a field on the group record itself. When evaluating access or sending notifications, ServiceNow builds a complete membership list that includes direct members, inherited members from child groups, and designated managers.

The Group Resolution Process

1. User or system triggers an action requiring group resolution (assignment, notification, access check)
2. ServiceNow queries sys_user_group to verify the group exists and is active
3. System reads direct group memberships from sys_user_grmember where group field matches the target group
4. If group hierarchy exists, system recursively queries child groups and includes their members
5. System adds group manager(s) from the manager field on the group record
6. Final user list is compiled and cached temporarily for the current transaction
7. Action proceeds with resolved user list (assignment notifications sent, access granted, etc.)

// Check if current user is member of specific group
function isUserInGroup(groupName) {
    var gr = new GlideRecord('sys_user_grmember');
    gr.addQuery('user', gs.getUserID());
    gr.addQuery('group.name', groupName);
    gr.query();
    return gr.hasNext();
}

// Get all active members of a group
function getGroupMembers(groupSysId) {
    var members = [];
    var gr = new GlideRecord('sys_user_grmember');
    gr.addQuery('group', groupSysId);
    gr.addQuery('user.active', true);
    gr.query();
    while (gr.next()) {
        members.push(gr.getValue('user'));
    }
    return members;
}

Real-World Scenarios

Creating Assignment Groups with Manager Hierarchy

Your organization needs to set up assignment groups for IT support teams where incidents can be assigned to the group, but escalations need to go to the group manager. This is the most common group configuration pattern in ServiceNow implementations.

Navigate to User Administration > Groups and click New. Set the Name to Network Support, check the Active checkbox, and select the team manager in the Manager field. After saving, use the Group Members related list to add team members by clicking Edit and selecting users from the slushbucket.

Building Group Hierarchy for Escalation Paths

You need to create a three-tier support structure where Level 1 incidents can escalate to Level 2, and Level 2 can escalate to Level 3, with automatic assignment group updates. This requires parent-child group relationships that many admins configure incorrectly.

Create three groups: IT Support L1, IT Support L2, and IT Support L3. On the L2 group record, set the Parent field to IT Support L1. On the L3 group record, set the Parent field to IT Support L2. Create assignment rules in System Policy > Assignment > Assignment Rules that check incident priority and automatically assign higher priorities to higher-level groups.

Setting Up Groups for Access Control and Field Visibility

Your security team requires that only members of a specific group can see sensitive fields on incident records, such as financial impact or executive escalation notes. This is a classic access control use case that requires both group setup and ACL configuration.

// ACL Script for sensitive field access
// Table: incident, Field: u_financial_impact, Type: read
answer = (function executeRule(current, previous) {
    // Allow admin and security_admin roles
    if (gs.hasRole('admin') || gs.hasRole('security_admin')) {
        return true;
    }
    
    // Check if user is member of Financial Review group
    var gr = new GlideRecord('sys_user_grmember');
    gr.addQuery('user', gs.getUserID());
    gr.addQuery('group.name', 'Financial Review Team');
    gr.query();
    
    return gr.hasNext();
})();

Create the group Financial Review Team and add appropriate users. Navigate to System Security > Access Control (ACL) and create a new rule with Type set to read, Name pointing to your sensitive field, and the script above in the Script field. This approach scales better than hardcoding user names and automatically handles group membership changes without requiring ACL updates.

The Classic Mistake

Admins frequently create groups like IT Support with no value in the Manager field, then set up a complex dynamic membership script that queries sys_user for anyone with department='IT'. They leave Include members checked and wonder why assignments fail intermittently. The dynamic script runs every time someone queries group membership, causing performance issues during peak hours.

// BAD: Complex dynamic membership for simple department groups
function isDynamic() {
    return true;
}

function getUsers() {
    var users = [];
    var gr = new GlideRecord('sys_user');
    gr.addQuery('department', 'IT');
    gr.addQuery('active', true);
    gr.addQuery('u_contractor', '!=', true);
    gr.query();
    while (gr.next()) {
        if (gr.manager.department == 'IT' && gr.location.u_support_enabled)
            users.push(gr.sys_id.toString());
    }
    return users;
}

This fails because dynamic membership queries execute during assignment routing, approval workflows, and ACL checks, causing timeout errors when the query takes too long. Users see assignments that disappear or approvals that route to nobody because the manager field is empty and the dynamic script fails silently. ServiceNow caches group membership inconsistently when dynamic scripts are involved, leading to users who can't see records they should have access to, or worse, seeing records they shouldn't. The performance impact compounds because every workflow, business rule, and ACL evaluation that touches the group triggers the dynamic script execution.

// GOOD: Static membership with proper manager
// Group: IT Support
// Manager: John Doe (IT Director)
// Members: Manually added or via scheduled job

// Scheduled Script for weekly membership sync
var gr = new GlideRecord('sys_user');
gr.addQuery('department', 'IT');
gr.addQuery('active', true);
gr.query();

var groupGr = new GlideRecord('sys_user_group');
groupGr.addQuery('name', 'IT Support');
groupGr.query();
if (groupGr.next()) {
    var ga = new GlideAggregate('sys_user_grmember');
    ga.addQuery('group', groupGr.sys_id);
    // Clear and rebuild membership weekly
}

When to Use This vs Alternatives

Use Groups when you need persistent collections of users for assignment, approval routing, or access control that will be referenced across multiple applications and workflows. Groups shine when you need to delegate administrative control through managers and when membership changes infrequently enough that static management is viable.

When Groups Are the Right Choice

Choose Groups over Roles when you need assignment queues, escalation paths, or approval workflows where the manager hierarchy matters. Groups provide the delegation model that Roles lack - you can't make someone a "manager" of the itil role, but you can make them manager of the Service Desk group. Groups also win when you need visible membership lists for operational purposes - seeing who's in the on-call rotation or approval chain.

When to Use Roles Instead

Use Roles for access control when membership is fluid and you need inheritance hierarchies - roles can contain other roles, groups cannot. Roles perform better in ACL evaluations because they're cached per user session, while group membership requires database lookups. Choose Roles when you need to grant capabilities (like admin or catalog_editor) rather than organizational membership.

When You Need Both Together

Enterprise implementations typically use Groups for organizational structure and assignment, with Roles for functional permissions. A user might be in the Network Team group (for incident assignment) and have the network_admin role (for CMDB access). This pattern works when you grant roles to entire groups using the Roles related list on the Group form, avoiding individual user management.

Platform Interactions & Side Effects

• Assignment Rules automatically populate assigned_to with the group manager when assignment_group is set and individual assignment is empty
• Approval workflows create sysapproval_approver records for each group member when group approval is configured, not just the manager
• ACL evaluation performs sys_user_grmember joins for every record access when using gs.getUser().isMemberOf() in scripts
• Update Sets capture group changes but not membership changes - sys_user_grmember records don't migrate automatically
• Notification recipients expand to include all group members when Groups/Roles field contains a group reference, creating individual sysevent_email_action records
• Business Rules trigger on sys_user_grmember insert/delete operations, not just group record changes, enabling member change notifications
• Dynamic groups cause session timeout issues because membership scripts execute during login when calculating user permissions
• Knowledge Base article permissions check kb_knowledge against group membership through can_read_user_criteria field evaluation
• Escalation rules write to task_escalation table and reassign records when group manager changes, potentially breaking audit trails
• Service Portal widget access controls use sp_rectangle and sp_widget group restrictions, breaking portal layouts when membership changes

Debugging and Troubleshooting

Group-related failures typically manifest as assignment routing errors, approval workflows that skip steps, or access control issues where users can't see records they should. Admins see assignments that remain unassigned with no error message, while users report that incidents "disappear" from their queues or approval requests never reach them. The most deceptive symptom is intermittent access - users can see a record sometimes but not others, usually indicating dynamic group membership script failures.

Start debugging in System Logs > System Log > All filtering for source com.glide.sys.security and com.glide.workflow - these capture ACL failures and workflow routing errors respectively. Use the Script Debugger on the group's dynamic membership script if defined, and check System Diagnostics > Session Debug > Debug Security for detailed ACL evaluation logs that show exactly which group checks are failing.

Look for error messages like "User [username] is not a member of group [group_name]" in System Log, or workflow context variables showing "Group has no active members" in Workflow > Workflow Context. Dynamic group scripts that time out produce "Script exceeded maximum execution time" entries. Assignment failures show as "Cannot assign to inactive user" when the group manager is inactive but the group is still being used for assignments.

Diagnostic Checklist:

• Verify group manager is active and has valid email in sys_user record
• Check sys_user_grmember table for actual membership records vs expected membership
• Test dynamic membership script manually in Scripts - Background with gs.log() output
• Validate assignment rules in System Policy > Rules > Assignment aren't conflicting with group assignments
• Confirm Include members setting matches intended behavior for notifications and approvals
• Review ACL debug logs for specific table/operation combinations failing group membership checks
• Verify notification schemes in affected workflows aren't sending to deactivated groups or members

Quick Reference

• Maximum 2000 direct members per group before performance degrades noticeably in member lookup operations
• Group names must be unique across sys_user_group table - no folder structure or namespacing available
• Dynamic groups with Include members unchecked still create sys_user_grmember records for caching
• Inactive groups still appear in assignment dropdowns unless explicitly filtered by business rules
• Group email addresses in Email field don't automatically route to members - custom notification logic required
• Deleting a group doesn't cascade delete sys_user_grmember records automatically in older instances
• Assignment rules evaluate in order but group-based rules don't inherit priority from data lookup rules
• Parent groups don't automatically grant child group permissions - no nested group inheritance
• LDAP integration creates groups with source field populated, preventing manual membership changes
• Knowledge Base access through groups requires Can Contribute flag enabled on group record, not just membership