Assignment Rule

What It Is

Assignment Rules are server-side automation that evaluates conditions against incoming or updated records and sets the Assignment Group and Assigned To fields automatically. They solve the fundamental problem of manual assignment overhead in high-volume environments where routing decisions follow predictable patterns based on record attributes like category, location, priority, or caller department. Rather than requiring agents to manually select groups or individuals for every ticket, assignment rules encode organizational knowledge into the platform and execute it consistently.

Assignment Rules live within the Service Management application under Assignment > Assignment Rules and operate at the platform's business logic layer alongside Business Rules and Workflows. They're stored in the sysrule_assignment table and extend the broader assignment infrastructure that includes Assignment Lookup Rules and Data Lookup Rules. Unlike client-side UI policies that only affect form behavior, assignment rules execute server-side during record saves, making them reliable for both interactive form submissions and programmatic record creation through imports, web services, or scripts.

The assignment rule engine integrates directly with ServiceNow's field processing pipeline, executing after field validation but before most Business Rules marked as before or async. This timing ensures assignment decisions happen early enough to influence subsequent automation like notifications or approval workflows that depend on knowing who owns the record. The rules evaluate against the current record state using standard condition builders, but they can also reference related records through dot-walking, allowing sophisticated assignment logic based on caller attributes, CI relationships, or organizational hierarchies stored elsewhere in the platform.

You cannot function without Assignment Rules in any environment handling significant record volumes across multiple specialized teams. Service desk operations with distinct groups for hardware, software, and network issues require automatic routing to prevent misassigned tickets from sitting unworked in wrong queues. Multi-location organizations need geographic assignment to ensure local teams handle local requests within business hours. Compliance-sensitive environments require certain categories of records to route only to certified or cleared personnel, making manual assignment both inefficient and risky from an audit perspective.

Platform administrators typically configure and maintain Assignment Rules since they require understanding both organizational structure and technical condition building. Developers become involved when advanced scripting conditions are needed or when assignment logic must integrate with custom applications or external systems. Process owners and team leads provide the business logic that drives rule conditions, but they rarely have direct access to modify rules themselves. The relationship between these roles becomes critical during organizational changes when assignment patterns must be updated to reflect new team structures, skill distributions, or escalation paths.

Recent ServiceNow releases have enhanced assignment rule performance and introduced better debugging capabilities, particularly around rule evaluation order and condition logging. The Vancouver release improved assignment rule execution within scoped applications, ensuring proper namespace isolation when custom applications define their own assignment logic. Xanadu and later versions provide clearer rule evaluation logs in System Logs > System Log > All when debug logging is enabled, making troubleshooting assignment issues significantly easier than in older platform versions.

Where to Find and Configure It

Navigate to Service Desk > Assignment > Assignment Rules to access the primary configuration interface where you create, modify, and order assignment rules. Each rule requires a table specification, condition logic, and assignment target configuration. Access System Definition > Tables and search for sysrule_assignment to view the underlying table structure and any custom fields added to extend rule functionality. Within Studio, assignment rules appear under Server Development > Assignment Rules when working within scoped applications that define custom assignment logic.

See assignment rules in action by examining the Assignment Group and Assigned To fields on target tables like incident, sc_request, or change_request as records get created or updated. Review assignment activity in System Logs > System Log > All with source assignment.rule when debug logging is enabled to troubleshoot rule execution and condition evaluation. Scoped applications can define assignment rules that only apply within their namespace, accessible through the scoped application's Studio interface but not visible in the global assignment rule list.

How It Works Step by Step

Assignment rules execute during the server-side record processing pipeline whenever a record is inserted or updated on a table that has active assignment rules configured. The system evaluates all active assignment rules for the target table in order sequence, checking each rule's conditions against the current record state including any field changes made during the current transaction. When a rule's conditions evaluate to true, the system immediately applies the specified assignment group and assigned user values, potentially overriding any existing assignments or previous rule results.

The assignment engine can reference related records through dot-walking during condition evaluation, allowing rules to assign based on caller department, location attributes, or configuration item relationships that aren't directly stored on the target record. Once assignment values are set, they become part of the record's field state for the remainder of the current transaction, influencing any subsequent business rules, workflows, or script includes that execute later in the processing pipeline. The system logs rule evaluation results when debug logging is enabled, capturing which rules fired and what assignments they made.

The Execution Order

1. Record insert or update triggers server-side processing
2. System queries for active assignment rules on the target table
3. Rules are evaluated in order sequence (lowest to highest numbers)
4. Each rule's conditions are checked against current record state
5. When conditions match, assignment group and user values are set immediately
6. Subsequent rules continue evaluating and can override previous assignments
7. Assignment processing completes before most business rules execute
8. Final assignment values are available to workflows, notifications, and other automation

// Advanced assignment rule script condition
// Assigns to network team during business hours, escalation team after hours

var caller = current.caller_id.getDisplayValue();
var callerDept = current.caller_id.department.getDisplayValue();
var currentHour = new Date().getHours();
var isBusinessHours = (currentHour >= 8 && currentHour < 17);

// Check if caller is from IT department and issue is network-related
if (callerDept == 'Information Technology' && 
    current.category == 'Network' && 
    current.priority.toString() == '1') {
    
    if (isBusinessHours) {
        current.assignment_group = 'Network Operations';
    } else {
        current.assignment_group = 'IT Escalation Team';
        current.priority = '1'; // Ensure high priority for after-hours
    }
    return true;
}
return false;

Real-World Scenarios

Geographic Assignment Based on Caller Location

Multi-location organizations need incidents automatically routed to regional support teams based on where the caller is physically located. This ensures local teams handle requests during appropriate business hours and reduces response time by eliminating cross-timezone handoffs for routine issues.

Create an assignment rule with Table set to Incident [incident] and conditions Caller > Location > Name CONTAINS New York. Set Assignment Group to NYC Service Desk and leave Assigned To empty to allow team-level assignment. Create similar rules for each location with appropriate Order values (100, 200, 300) and a final catch-all rule with higher order number for unmatched locations.

Category-Based Skills Assignment with Overflow Logic

Specialized technical teams require automatic assignment based on incident category, but high-priority issues need to escalate immediately to senior resources when standard teams are unavailable. This prevents critical issues from sitting in queue while maintaining normal workload distribution for routine requests.

// Assignment rule with overflow logic for high-priority database issues

var isHighPriority = (current.priority == '1' || current.priority == '2');
var isDatabaseIssue = current.category == 'Database';
var isBusinessHours = new Date().getHours() >= 8 && new Date().getHours() < 18;

if (isDatabaseIssue) {
    if (isHighPriority && !isBusinessHours) {
        // After hours critical database issues go to DBA escalation
        current.assignment_group = 'Database Administration - Escalation';
        current.assigned_to = '';
    } else if (isHighPriority) {
        // Business hours critical issues go to senior DBAs
        current.assignment_group = 'Database Administration - Senior';
    } else {
        // Normal priority database issues go to standard team
        current.assignment_group = 'Database Administration';
    }
    return true;
}
return false;

Configure this as a script condition assignment rule with Order set to 50 so it runs before general category-based rules. Ensure assignment group names match exactly with existing groups in User Administration > Groups. Test rule logic thoroughly since script conditions bypass the standard condition builder's validation and can fail silently with typos or invalid field references.

Department-Based Request Routing with Manager Escalation

Service requests from specific departments need automatic assignment to designated support staff who understand department-specific processes and systems. High-value requests or those from executive staff require immediate assignment to department liaisons rather than general queue processing.

Create separate assignment rules for each department with conditions Requested for > Department > Name IS Finance and Assignment Group set to Finance IT Support. Add a higher-priority rule with conditions Requested for > Department > Name IS Finance AND Requested for > VIP IS true that assigns directly to Assigned To the designated VIP support specialist. Set the VIP rule Order lower than department rules so it evaluates first.

The Classic Mistake

// Rule 1: Order 100
// Table: incident
// Condition: category == 'software'
assignment_group = 'Software Support';

// Rule 2: Order 200  
// Table: incident
// Condition: category == 'software' && subcategory == 'email'
assignment_group = 'Email Team';

// Rule 3: Order 300
// Table: incident  
// Condition: category == 'software' && priority <= 2
assignment_group = 'Critical Software Team';

// Result: A P1 email incident gets assigned to Software Support
// instead of Critical Software Team because Rule 1 runs first

This fails because assignment rules execute in Order sequence, and the first matching rule wins—period. Users see incidents consistently routed to the wrong teams, especially for edge cases that should match multiple rules. ServiceNow doesn't evaluate "best match" or "most specific condition"—it stops at the first true condition and executes that rule's script. The symptom is maddeningly inconsistent assignment that seems logical when you look at individual rules but breaks down in practice.

// Rule 1: Order 100 - Most Specific First
// Condition: category == 'software' && subcategory == 'email' && priority <= 2
assignment_group = 'Critical Email Team';

// Rule 2: Order 200 - Next Most Specific
// Condition: category == 'software' && subcategory == 'email'
assignment_group = 'Email Team';

// Rule 3: Order 300 - Critical Catch-All
// Condition: category == 'software' && priority <= 2
assignment_group = 'Critical Software Team';

// Rule 4: Order 400 - General Catch-All
// Condition: category == 'software'
assignment_group = 'Software Support';

When to Use This vs Alternatives

Assignment Rules are the right choice when you need consistent, condition-based routing that applies across create and update operations without custom code. They excel at straightforward field-based logic that maps cleanly to "if this, assign to that" scenarios.

Use Assignment Rules When

You need declarative assignment logic based on form fields, categories, or user attributes that non-technical admins can maintain. Business Rules require scripting knowledge and Workflow is overkill for simple field-based routing. Assignment Rules provide the visual condition builder and centralized management that makes ongoing maintenance feasible for functional admins.

Use Business Rules Instead When

You need complex logic involving calculations, external system lookups, or advanced GlideRecord queries to determine assignment. Assignment Rules can't call web services, perform aggregations, or implement sophisticated algorithms. Business Rules give you full scripting power for scenarios like workload balancing, skills-based routing, or assignments that depend on real-time data from other tables.

Use Both Together When

You have a hybrid scenario: Assignment Rules handle the standard 80% of cases with simple field-based logic, while Business Rules catch the complex exceptions. Set Assignment Rules to lower Order values (100-500) for common patterns, then use Business Rules with higher Order values (1000+) to override assignments for special cases that require scripted logic.

Platform Interactions & Side Effects

• Triggers Business Rules that run on before and after the assignment group or assigned to field changes, potentially causing infinite loops if Business Rules modify fields that trigger assignment rules
• Creates entries in sys_audit table for assignment group and assigned to field changes, which impacts audit reports and can consume significant database space on high-volume tables
• Notification rules fire when assignment fields change via assignment rules, sending emails to new assignees even during bulk imports or data loads unless you disable sys.email.enabled system property
• SLA workflow tasks and business rules that depend on assignment group execute immediately when assignment rules set the group, potentially starting SLA timers before other required fields are populated
• ACL evaluation runs against the user context that triggered the assignment rule, not the assigned user, which can cause permission issues when assignment rules run during scheduled jobs or system updates
• Update Sets capture assignment rule changes but deployment can fail silently if target instance lacks referenced groups in the sys_user_group table that are hardcoded in rule scripts
• Transform Maps skip assignment rules by default unless Run Business Rules is checked, causing imported records to bypass normal assignment logic
• Performance degrades on tables with many assignment rules because every create/update evaluates all active rules in order until one matches, with no query optimization or early exit strategies
• Mobile app assignment changes trigger assignment rules when records sync back to the server, potentially overriding manual assignments made by field technicians
• Domain separation evaluates assignment rules within the record's domain context, so rules may fail to assign cross-domain groups unless explicitly allowed by domain configuration

Debugging and Troubleshooting

The most common failure symptom is records that should match an assignment rule remaining unassigned or getting assigned to unexpected groups. Users report inconsistent assignment behavior, especially when records are updated through different channels (web UI, email, API, mobile). Admins typically see this as scattered complaints about "the system assigning tickets to the wrong team" without obvious patterns.

Start troubleshooting in System Logs > System Log > All filtering for "Assignment Rule" messages. Enable debug logging by setting glide.assignment_rules.log_level=debug system property to see which rules are evaluated and why they succeed or fail. The Business Rule debugger under System Diagnostics > Session Debug > Debug Business Rules shows assignment rule execution in real-time during record operations.

Look for error messages like "Assignment group [group_name] not found" or "User [user_name] is not active" in the logs, which indicate script errors or data integrity issues. JavaScript errors in assignment rule conditions show as "ReferenceError" or "TypeError" messages. Performance issues appear as "Business Rule exceeded maximum execution time" warnings when assignment rule scripts take too long to execute.

Diagnostic Checklist:

• Check if assignment rules are active and verify the Table field matches your record's table exactly
• Test assignment rule conditions in isolation using Scripts - Background with the same field values as your problem record
• Verify assignment group exists and is active in sys_user_group table and users exist in sys_user with active=true
• Review assignment rule Order values to ensure higher-priority rules aren't overriding expected matches
• Check for Business Rules or Client Scripts that modify assignment fields after assignment rules execute
• Examine domain configuration if using domain separation—rules only assign within accessible domains
• Test with different user contexts to verify ACL and role-based assignment restrictions aren't blocking rule execution

Quick Reference

• Assignment rules have a hard limit of 16KB for the script field, preventing complex multi-hundred-line assignment logic
• The assignment_group and assigned_to variables in scripts accept sys_ids, not display names—use gs.getUser().getID() for current user
• Assignment rules ignore child table inheritance—create separate rules for incident, problem, and change tables even if they extend task
• Rules execute during before business rule phase at priority 0, before any custom business rules with positive order values
• Setting assigned_to = '' in assignment rule scripts clears the assigned to field but leaves assignment group populated
• Performance degrades significantly after 50+ active assignment rules on the same table due to sequential condition evaluation
• Assignment rules don't fire during setWorkflow(false) operations or when autoSysFields(false) is set in scripts
• The condition builder's "changes to" operator only works on update operations and fails silently on insert operations
• Referencing current.assignment_group in assignment rule conditions creates circular logic that can prevent rules from executing correctly
• Clone operations bypass assignment rules unless the target table has Clone with Business Rules enabled in table configuration