Assignment Group

What It Is

Assignment Group is the foundational mechanism that determines which team owns and works a task record in ServiceNow. The assignment_group field stores a reference to the sys_user_group table, creating the binding between work items and the teams responsible for resolving them. This isn't just about organization—it's the primary driver for routing, escalation, notifications, and workload distribution across your entire ITSM operation. Without proper assignment group configuration, tickets disappear into queues, SLAs fire incorrectly, and teams lose visibility into their work.

Architecturally, Assignment Group lives in the core Task application layer, inherited by every task-based table including Incident, Service Request, Change, Problem, and any custom task extensions. The field appears on the task table itself, meaning it's automatically available across all task types without additional configuration. The reference relationship connects to the Group module under User Administration, where the actual group records are managed. This design ensures consistent behavior whether you're dealing with a Priority 1 incident or a standard access request—the assignment mechanism works identically across all task types.

The data model relationship extends beyond simple storage—assignment groups integrate with ServiceNow's notification framework, assignment rules engine, and SLA definitions. When a task's assignment group changes, it triggers a cascade of platform behaviors: notifications fire to group members, SLA conditions re-evaluate, and related lists update to reflect new ownership. The sys_user_grmember table maintains the many-to-many relationship between users and groups, while the sys_user_group_type field on groups controls whether they appear in assignment group reference qualifiers.

You cannot function without assignment groups in any multi-team ServiceNow implementation. Service desk operations require assignment groups to route incidents to Level 1, Level 2, and specialist teams based on categorization or escalation triggers. Change management depends on assignment groups to ensure changes reach the appropriate approval and implementation teams—CAB reviews, infrastructure teams, and application owners all rely on proper assignment routing. Request fulfillment uses assignment groups to distribute catalog items to the teams that actually provision access, deploy software, or fulfill services. Without this mechanism, work items become orphaned, teams lose visibility into their queues, and your entire ITSM process breaks down into manual email chains and phone calls.

Platform administrators typically manage the group records themselves and the assignment rule configurations that populate assignment groups automatically. Developers handle the advanced scenarios—custom assignment logic in business rules, integration assignment from external tools, and complex assignment workflows that involve multiple decision points. Process owners and team leads work with admins to define the assignment criteria and ensure their teams receive the right work. The division of responsibility usually breaks down with admins handling the configuration mechanics while business stakeholders define the routing logic and team structures.

Recent platform versions haven't dramatically changed assignment group core functionality, but Vancouver and later releases improved the assignment rule engine performance and added better debugging capabilities in the Assignment Rule module. The Group application in the Now Platform also received UI updates that make group member management more intuitive, particularly around bulk member operations and group type filtering. Xanadu enhanced the reference qualifier performance for assignment group fields, reducing load times on forms with large group datasets.

Where to Find and Configure It

The primary configuration location is User Administration > Groups where you create and manage the actual group records that serve as assignment targets. Navigate to System Policy > Rules > Assignment to configure automated assignment rules that populate the assignment group field based on conditions. For field-level configuration including reference qualifiers and form layout, go to System Definition > Tables and open the specific task table you're working with.

In Studio or App Engine Studio, find assignment group configurations under the Data Model section when viewing table definitions, and under Process Automation for assignment rules scoped to your application. The assignment group field appears on task forms by accessing System UI > Forms and selecting the appropriate task table and form view. You can see assignment groups in action by navigating to any task-based module like Incident > All or Change > All where the assignment group appears as a column in list views and a field on individual records.

Global application scope allows you to create assignment rules that affect any task table across the entire instance, while scoped applications can only create assignment rules for tables within their scope. The group records themselves are always global, but scoped applications can reference them in their assignment logic. Access the actual sys_user_group table directly via System Definition > Tables > Groups if you need to perform bulk operations or examine the underlying data structure.

How It Works Step by Step

Assignment groups operate through a combination of manual assignment, automated assignment rules, and programmatic assignment via business rules or scripts. When a task record is created or updated, ServiceNow first checks if the assignment_group field has been explicitly set by a user or integration. If not populated, the system evaluates active assignment rules in order, checking conditions against the current record state. The first matching rule fires and sets the assignment group value, while subsequent rules are skipped.

Once assigned, the assignment group drives downstream behaviors through the platform's event system. Notifications configured for assignment group changes fire immediately, sending alerts to group members or managers based on your notification rules. SLA definitions that reference assignment groups re-evaluate their conditions and timelines. Related lists and dashboards that filter by assignment group update their queries to reflect the new ownership. The assignment also integrates with ServiceNow's approval framework—many approval rules use assignment group membership to determine appropriate approvers for changes or requests.

The Assignment Execution Order

1. User submits or updates a task record through form submission, import, integration, or API call
2. ServiceNow checks if assignment_group field contains a value—if populated, skip to step 6
3. System evaluates active assignment rules in order (lowest order number first) for the specific table
4. First rule with matching conditions executes, setting assignment group value and stopping further rule evaluation
5. Before business rules execute, reading current assignment group value and potentially overriding it
6. Record saves with final assignment group value, triggering notifications and SLA evaluations
7. After business rules fire for additional processing based on the new assignment group value

// Before business rule - dynamic assignment based on location
(function executeRule(current, previous) {
    
    // Only assign if not already assigned
    if (current.assignment_group.nil()) {
        
        var locationCode = current.location.getDisplayValue();
        var assignmentGroup = '';
        
        // Route based on user's location
        if (locationCode.indexOf('NYC') >= 0) {
            assignmentGroup = 'New York IT Support';
        } else if (locationCode.indexOf('LON') >= 0) {
            assignmentGroup = 'London IT Support';
        } else {
            assignmentGroup = 'Global IT Support';
        }
        
        // Find and assign the group
        var group = new GlideRecord('sys_user_group');
        if (group.get('name', assignmentGroup)) {
            current.assignment_group = group.sys_id;
            gs.info('Auto-assigned to: ' + assignmentGroup);
        }
    }
    
})(current, previous);

Real-World Scenarios

Multi-Tier Support Assignment Based on Impact and Urgency

Your service desk needs to automatically route high-impact incidents to senior support tiers while keeping routine issues with Level 1 support. Priority 1 and 2 incidents should skip Level 1 entirely and go straight to Level 2 or specialized teams based on the affected service.

Create assignment rules in System Policy > Rules > Assignment with order 100 for critical incidents: condition priority=1^ORpriority=2 assigning to 'Level 2 Support'. Add order 200 for business service incidents: condition business_service.nameSTARTSWITHEmail^priority=1 assigning to 'Email Support Team'. Set order 300 as catchall: condition priority>=3 assigning to 'Level 1 Support'.

Location-Based Assignment for Global Service Desk

Your organization operates service desks in multiple time zones and needs to route incidents to the appropriate regional team based on the caller's location. Follow-the-sun support requires automatic assignment to ensure requests reach teams during their business hours.

// Assignment rule advanced condition script
(function() {
    var callerLocation = current.caller_id.location.getDisplayValue();
    var currentHour = new GlideDateTime().getLocalTime().getHour();
    
    // Americas region (6 AM - 6 PM local)
    if (callerLocation.indexOf('Americas') >= 0) {
        if (currentHour >= 6 && currentHour <= 18) {
            return 'Americas Support';
        }
    }
    
    // EMEA region (8 AM - 8 PM local) 
    if (callerLocation.indexOf('Europe') >= 0 || callerLocation.indexOf('EMEA') >= 0) {
        if (currentHour >= 8 && currentHour <= 20) {
            return 'EMEA Support';
        }
    }
    
    // Default to global support outside business hours
    return 'Global 24x7 Support';
    
})()

Configure this as an advanced assignment rule with the script result determining the assignment group name. Create corresponding groups in User Administration > Groups with exact names matching your script return values. Watch for timezone conversion issues between the server and user locations—test thoroughly across different user profiles and time periods.

Catalog Item Assignment to Fulfillment Teams

Service catalog requests need automatic routing to the teams that actually fulfill them—software requests to the software deployment team, hardware to procurement, access requests to identity management. Each catalog item should route to its appropriate fulfillment team without manual intervention.

Add a custom field u_fulfillment_group (reference to sys_user_group) on the sc_cat_item table. Configure each catalog item with its fulfillment team. Create a business rule on sc_req_item (before insert) that copies the fulfillment group from the catalog item: current.assignment_group = current.cat_item.u_fulfillment_group. This ensures every requested item immediately routes to the correct team upon submission.

The Classic Mistake

The worst configuration involves creating multiple groups named "Network Team" or "Application Support" across different business units without establishing clear assignment rule precedence. Admins typically create a group called Network Team under IT Operations, then later create another Network Team under Facilities, both with similar assignment rule conditions checking for category = 'network'. The assignment rules end up with overlapping conditions like short_description CONTAINS network without considering order execution or specificity.

// Assignment Rule #1 (Order: 100)
// Target Group: IT Operations > Network Team
if (current.category == 'network') {
  current.assignment_group = '8a8b2c3d4e5f6789012345678901234';
}

// Assignment Rule #2 (Order: 200) 
// Target Group: Facilities > Network Team  
if (current.short_description.indexOf('network') > -1) {
  current.assignment_group = '9b9c3d4e5f67890123456789012345a';
}

// Assignment Rule #3 (Order: 300)
// Target Group: Security > Network Team
if (current.location.building == 'HQ' && current.category == 'network') {
  current.assignment_group = 'ab0c4d5e6f78901234567890123456b';
}

This fails because ServiceNow executes assignment rules in order, and the first matching condition wins regardless of how specific later rules might be. Users see tickets getting assigned to the wrong team consistently, especially when generic conditions match before specific ones. The system processes rules sequentially by the Order field value, so a broad rule at order 100 will always override a precise rule at order 200. What makes this non-obvious is that the assignment rule list shows all rules as "active" without indicating which one actually executed for a given ticket.

// Assignment Rule #1 (Order: 100)
// Most specific conditions first
if (current.location.building == 'HQ' && 
    current.category == 'network' && 
    current.u_network_type == 'security') {
  current.assignment_group = 'ab0c4d5e6f78901234567890123456b'; // Security Network Team
}

// Assignment Rule #2 (Order: 200)
// Medium specificity 
if (current.category == 'network' && 
    current.u_network_type == 'infrastructure') {
  current.assignment_group = '8a8b2c3d4e5f6789012345678901234'; // IT Ops Network Team
}

// Assignment Rule #3 (Order: 300)
// Catch-all for remaining network items
if (current.category == 'network') {
  current.assignment_group = '9b9c3d4e5f67890123456789012345a'; // General Network Team
}

When to Use This vs Alternatives

Use assignment groups when you need persistent team ownership with clear accountability for ticket resolution and the ability to reassign work within a defined group structure. This is the primary mechanism for routing tickets to functional teams that have ongoing responsibility for specific types of work, whether that's application support, infrastructure maintenance, or business process management.

When Assignment Groups Are the Right Choice

Choose assignment groups for tickets that require team-based resolution, ongoing ownership, or specialized knowledge that exists within a specific organizational unit. Individual user assignment fails here because team members take vacation, change roles, or need to collaborate on complex issues. Distribution lists or notification groups can't handle the accountability aspect since they lack the workflow integration and reporting capabilities that assignment groups provide through the sys_user_group table structure.

When to Use Direct Assignment Instead

Use direct individual assignment via the assigned_to field for tickets that require specific expertise from a known individual, have personal accountability requirements, or involve sensitive information that shouldn't be visible to an entire team. Personal tasks, executive requests, and highly specialized technical work often fall into this category. Assignment groups create unnecessary overhead when you already know exactly who needs to handle the work and that person has unique qualifications or access requirements.

When You Need Both Together

Implement both assignment group and individual assignment when you need team oversight with individual accountability, such as junior staff requiring senior review, or complex projects where a primary owner needs team support. The typical pattern assigns tickets to a group initially for visibility and SLA tracking, then assigns to individuals within that group for actual work execution. Many organizations use this dual approach for change management, where the Change Advisory Board group maintains oversight while individual change managers handle specific requests.

Platform Interactions & Side Effects

• ACL evaluation uses assignment group membership for gs.getUser().isMemberOf() checks, impacting field visibility and record access across all tables
• SLA calculations trigger differently based on assignment group changes, writing to task_sla table and potentially resetting breach timers
• Notification recipients expand automatically to all group members unless specifically configured with Advanced condition scripts in notification records
• Assignment audit trail gets recorded in sys_audit table with field name assignment_group showing old and new sys_id values
• Business Rules with current.assignment_group.changes() conditions fire on every assignment group modification, including null assignments
• Performance Analytics widgets break when assignment groups get deleted instead of deactivated, leaving orphaned references in assignment_group fields pointing to non-existent sys_ids
• Update Sets capture assignment rule modifications but not the sys_user_group records they reference, causing deployment failures in target instances
• Domain separation affects assignment group visibility through sys_user_group.sys_domain field, potentially hiding valid assignment targets in cross-domain scenarios
• Email routing relies on assignment group's email field for automated responses, but this breaks when groups lack email addresses or use distribution lists that don't accept external mail
• Assignment group changes clear the assigned_to field automatically unless blocked by business rule, affecting individual accountability tracking

Debugging and Troubleshooting

The most common failure symptom is tickets getting assigned to unexpected groups or remaining unassigned despite having active assignment rules. Users report that their tickets "went to the wrong team" or "nobody got notified," while admins see assignment rules that appear correctly configured but don't execute as expected. This typically manifests as either the wrong group getting assigned (indicating rule order problems) or no assignment happening at all (indicating condition logic failures).

Start troubleshooting in System Logs > System Log > All filtering for the ticket number and looking for assignment rule execution messages. Enable debugging by setting the system property glide.script.log.level to debug and adding gs.log() statements in assignment rule conditions to trace execution flow. The Script Debugger helps when assignment rules contain complex JavaScript logic, but remember it only captures server-side script execution.

Look for specific error messages like "Assignment group is not accessible" in the application logs, which indicates ACL or domain separation issues. Check the sys_user_group table directly to verify that target groups exist and are active—deleted groups leave behind sys_id references that cause silent assignment failures. Assignment rules that reference non-existent groups will execute without error but produce no visible assignment, making this particularly difficult to diagnose without checking the actual group records.

Diagnostic Checklist:

• Verify assignment rule order by checking Order field values in System Policy > Rules > Assignment
• Test assignment rule conditions manually using Scripts - Background with actual ticket data
• Confirm target assignment groups exist and are active in sys_user_group table
• Check assignment rule table filters and conditions for syntax errors or invalid field references
• Review domain separation settings if using multiple domains—groups may be hidden from assignment rules
• Validate that Business Rules aren't overriding assignment group values after assignment rules execute
• Examine sys_audit records to trace assignment group changes over time for the affected ticket

Quick Reference

• Assignment rules execute in order by Order field value, first match wins—subsequent rules with lower order values never execute
• Maximum assignment rule condition script length is 8000 characters, stored in sys_assignment.script field
• Assignment group changes automatically clear assigned_to field unless system property glide.ui.assignment.clear_assigned_to is set to false
• Deleted assignment groups break Performance Analytics widgets and reports—always deactivate instead of delete
• Assignment rules don't execute on records created via Import Sets unless Run business rules is enabled in transform map
• Domain-separated assignment groups require can_read ACL access for assignment rules to select them as targets
• Assignment group email field supports only single email addresses—distribution lists require separate notification configuration
• Virtual Agent and Flow Designer assignment actions bypass assignment rules entirely, setting assignment_group field directly
• Update Set deployment fails if referenced assignment groups don't exist in target instance—no automatic dependency resolution
• Assignment group membership changes don't trigger assignment rule re-evaluation on existing tickets—only new assignments or manual changes