Assignment & Routing Pack

sn-route-001

Predictive Intelligence for Initial Incident Assignment

Predictive Intelligence Priority: Critical Effort: Medium

To automate the initial assignment of incidents to the correct group by predicting the assignment group from the short description, thereby reducing the significant 8-hour average delay from 'New' to 'Assigned' and mitigating the high-volume 'Assigned -> Active' rework loop.

Why this pack: This rule directly addresses the core function of initial ticket routing by leveraging machine learning to improve accuracy and speed, which is a primary focus of the Assignment & Routing pack.

Trigger

Incident is created.

Conditions

·Assignment group is empty

·Short description is not empty

Actions

·Predict the 'assignment_group' field based on the 'short_description'.

·If prediction confidence is above a defined threshold (e.g., 60%), set the Assignment group.

·Update the incident state from 'New' to 'Assigned'.

Evidence used

·Transition: New -> Active (Avg 3.27 hrs)

·Transition: Active -> Assigned (Avg 4.60 hrs)

·Transition: Assigned -> Active (35.60% of tasks, rework)

·Variant: 'New -> Active -> Assigned -> Active -> Assigned -> Closed' (7.80% of tasks)

ServiceNow implementation

Target table

·incident

Configuration area

·Predictive Intelligence

Configuration trigger

·On record creation

Configuration conditions

·current.assignment_group.nil()

Implementation steps

·Navigate to Predictive Intelligence > Classification > Solution Definitions.

·Create a new Solution Definition for the 'incident' table.

·Set the 'Input Field' to 'short_description' and the 'Output Field' to 'assignment_group'.

·Use the last 6-12 months of resolved incident data as the training set (minimum 10,000 records recommended).

·Train the solution and review the precision/coverage results.

·Create a Business Rule or Flow Designer trigger on Incident creation.

·In the script/flow, call the PI prediction API (e.g., `sn_ml.Classification.predict`).

·If the confidence score returned is > 0.60, set `current.assignment_group` to the predicted value and set `current.state` to the value for 'Assigned'.

Fields used

·short_description

·assignment_group

·state

Test cases

·Create a new incident with short description 'VPN connection drops intermittently'. Verify it is assigned to the correct network team.

·Create a new incident with a vague short description. Verify the assignment group remains empty for manual triage if prediction confidence is low.

Rollback notes

·Disable the Business Rule or Flow that applies the prediction to stop auto-assignment.

Requirements / prerequisites

·ServiceNow ITSM Pro license.

·Predictive Intelligence plugin (com.glide.platform_ml) enabled.

·Sufficient historical incident data (10k+ records) for training the ML model.

sn-route-002

Reduce Assignment Ping-Pong with Reassignment Guardrail

Flow Designer Priority: High Effort: Medium

To reduce incorrect reassignments and 'ping-pong' behavior by requiring a work note justification when a ticket is sent back from an assigned state to an unassigned state. This targets the most frequent rework loop identified in the process.

Why this pack: This rule establishes a governance control directly on the assignment process to improve quality and reduce churn between assignment groups, a key goal of routing optimization.

Trigger

Incident 'assignment_group' changes to empty from a non-empty value, AND 'Assigned to' changes to empty.

Conditions

·State is 'Assigned' or 'Work in Progress'.

·The previous value of 'assignment_group' was not empty.

Actions

·Check if a work note was added by the current user in the last minute.

·If no recent work note exists, abort the update.

·Display a message to the user: 'Reassignment requires a work note explaining why this group cannot handle the incident.'

Evidence used

·Transition: Assigned -> Active (35.60% of tasks, rework)

·Variant: 'New -> Active -> Assigned -> Active -> Closed' (7.60% of tasks)

·High overall rework percentage, consistently over 50%.

ServiceNow implementation

Target table

·incident

Configuration area

·Business Rule

Configuration trigger

·Before update, when Assignment group changes to empty

Configuration conditions

·!previous.assignment_group.nil() && current.assignment_group.nil()

Implementation steps

·Create a 'before' update Business Rule on the 'incident' table.

·Set the condition to 'Assignment group changes to empty'.

·In the script, query the `sys_journal_field` table for a work note (`element` = 'work_notes') on the current incident (`element_id` = current.sys_id) created by the current user (`sys_created_by` = gs.getUserName()) in the last 2 minutes (`sys_created_on` > gs.minutesAgo(2)).

·If the query returns no records, set `current.setAbortAction(true)` and use `gs.addErrorMessage()` to display a blocking message to the user.

·Ensure the rule order is low (e.g. 50) to run before other rules.

Fields used

·assignment_group

·assigned_to

·work_notes

·state

Test cases

·Open an incident assigned to 'Group A'. Clear the 'Assignment group' field and try to save. Verify the action is aborted with an error message.

·Open an incident assigned to 'Group A'. Add a work note. Immediately clear the 'Assignment group' field and save. Verify the update is successful.

Rollback notes

·Deactivate the Business Rule.

Requirements / prerequisites

·Permissions to create Business Rules on the incident table.

sn-route-003

Decision Table for Common Hardware & Software Incidents

Decision Table Priority: High Effort: Low

To provide fast, accurate, and easily maintainable routing for high-volume, predictable incidents based on keywords in the short description. This will offload volume from manual triage and improve first-assignment accuracy for the most common issues.

Why this pack: This rule uses a core routing capability (Decision Tables) to map specific inputs (incident data) to a specific output (assignment group), which is fundamental to the Assignment & Routing pack.

Trigger

Incident is created.

Conditions

·Assignment group is empty

Actions

·A Flow Designer subflow or Business Rule calls the decision table.

·The decision table uses the 'short_description' as an input.

·If a match is found, the resulting 'assignment_group' is populated on the incident.

Evidence used

·Sample Task Summaries include repetitive themes: 'Server disk space critical', 'Software installation failing', 'Email attachments not opening', 'Printer not responding', 'Laptop will not power on'.

·High volume of tickets with similar priorities and SLA definitions, suggesting common issue types.

ServiceNow implementation

Target table

·incident

Configuration area

·Decision Builder

Configuration trigger

·Called from a Flow or Business Rule on Incident creation

Configuration conditions

·Input: Incident Record > Short description

Implementation steps

·Navigate to Decision Management > Decision Builder and create a new Decision Table.

·Define an Input column based on the Incident's 'short_description' field (Condition type: contains).

·Define an Output column that results in an 'Assignment Group' reference.

·Create rows for common issues. E.g., Input 'short_description' contains 'printer', Output Group = 'Desktop Support'. Input contains 'disk space', Output Group = 'Server Team'. Input contains 'VPN', Output Group = 'Network Team'.

·Create a Flow Designer flow that triggers on Incident creation when 'assignment_group' is empty.

·Add the 'Make a Decision' flow logic step, referencing the new decision table.

·Add an 'Update Record' step to set the 'assignment_group' on the Incident with the result from the decision.

·Ensure this runs before the Predictive Intelligence rule (sn-route-001) to handle deterministic cases first.

Fields used

·short_description

·assignment_group

Test cases

·Create an incident with short description 'The printer on floor 3 is offline'. Verify it is assigned to 'Desktop Support'.

·Create an incident with short description 'Critical alert for server disk space'. Verify it is assigned to 'Server Team'.

Rollback notes

·Deactivate the Flow Designer flow that calls the decision table.

Requirements / prerequisites

·Decision Builder plugin (com.glide.decision_builder) is active.

·Analysis to determine common keywords and map them to the correct fulfillment groups.

sn-route-004

Route by Contact Type for Specialized Queues

Assignment Rule Priority: Medium Effort: Low

To route incidents based on their entry channel (contact type) to specialized teams. This ensures incidents from critical integrations or those requiring specific handling (e.g., phone calls) are triaged by the appropriate first-level group.

Why this pack: This rule utilizes ServiceNow's foundational Assignment Rule capability to direct tickets based on record data at the point of creation, a classic and essential assignment strategy.

Trigger

Incident is created.

Conditions

·Assignment group is empty

Actions

·Assign the incident to a specific group based on the 'contact_type' value.

Evidence used

·Field Usage: 'contact_type' is well-populated with diverse values like 'Integration' (15.3%), 'Phone' (12.9%), and 'Virtual Agent' (11.9%).

·The fragmented assignment group structure suggests some groups might be dedicated to specific intake channels or projects, but this is not being enforced systematically.

ServiceNow implementation

Target table

·incident

Configuration area

·Assignment Rule

Configuration trigger

·On record creation

Configuration conditions

·Varies by rule entry.

Implementation steps

·Navigate to System Policy > Rules > Assignment.

·Create a new Assignment Rule for the 'Incident' table.

·Create the first entry with Order 100. Condition: 'Contact type' is 'Phone'. Set 'Assign to' group to 'Service Desk Voice'.

·Create a second entry with Order 110. Condition: 'Contact type' is 'Integration'. Set 'Assign to' group to 'Integration Support L1'.

·Create a third entry with Order 120. Condition: 'Contact type' is 'Virtual Agent'. Set 'Assign to' group to 'Service Desk Chat'.

·Ensure this assignment rule runs before other, more specific routing logic like Decision Tables or PI.

Fields used

·contact_type

·assignment_group

Test cases

·Create an incident with contact_type = 'Phone'. Verify it is assigned to 'Service Desk Voice'.

·Create an incident with contact_type = 'Email'. Verify the assignment group remains empty for other rules to process.

Rollback notes

·Deactivate the assignment rule entries or the main assignment rule itself.

Requirements / prerequisites

·Clearly defined assignment groups for each contact type.

·Agreement on which channels require specialized first-level triage.