The scoped version of HR ships out of box with automatic case assignment functionality. The idea behind this functionality is to assign a case to the least loaded agent who has all the skills listed on the case and whose user location matches the subject person’s user location. Here is a brief description of how the assignment rules work and how a customer may want to modify the OOB functionality.
Step 1: The Auto Assign Business Rule
HR Case has a business rule called “Auto Assign” which invokes the matching rule logic (screenshot below). The condition is dependent on state, assignment group not being null, and assigned to being null. Note that for specific HR Services, the auto assignment functionality can be skipped. See "Case options" in Create or modify an HR service. If auto assignment is triggered, then we invoke Matching Rules logic to get a list (second parameter specifies length of list) of agents via the call to matchingRuleProcessor.processAndGetCandidates(current,1). If a customer wants to see additional agents that matched they could change the second argument to something greater than one. A quick and dirty way of exposing the results would be add an info message with agent names. Fancier would be to expose in a UI (as the Customer Service application has done).
Step 2: Matching Rules
HR Assignment Rules makes use of the Resource Matching Engine plugin. This lets us specify a table (e.g., HR Payroll Case) and a condition (OOB we always specify Assignment group is empty and Assigned to is not empty). For cases that meet the condition we make a call to a script include to get a list of agents that are eligible for assignment to the given case.
To see this in the system navigate to HR Administration --> HR Matching Rules which filters to matching rules on the out of box HR tables, or navigate to Routing and Assignment --> Matching Rules to see all matching rules. As seen in the following screenshot, we provide a pair of matching rules for each of our COE tables and for the HR Task table.
The higher priority (lower execution order) rule for each pair is the “match by skills and country” one. If that one doesn’t find any eligible agents then the condition on the lower priority rule will still be true and we fallback to it and attempt to match by skills alone. If the higher priority rule finds an agent, then the assigned to field is no longer empty and the secondary rule does not match.
The below screenshot is a look at the scripted part of the rule.
The OOB rules will call either getAgentsByCountryAndSkillsOrderLeastLoaded or getAgentsBySkillOrderLeastLoaded in the hr_AssignmentAPI script include. The “current” is the HR case (e.g., HR Payroll Case in the screenshot).
Step 3: The assignment script includes
The hr_AssignmentAPI just passes the call through to the hr_AssignmentUtil script include. The purpose of that was to try and reduce upgrade issues as we expect that customers will have their own assignment logic that they will want to implement. Rather than modifying hr_AssignmentUtil which has been updated by ServiceNow several times since the initial release, the expectation is that customer methods would be added to hr_AssignmentAPI or another customer script include.
The method that looks for least ordered by country and skills looks at the agents in the assignment group and does an intersection of agents who have the case’s required skills and the agents whose country is the same as the subject person’s country. The resulting list of agents is sorted according to load, which is defined as active cases of type HR Case (or extension) or active HR Tasks.
The assignment of HR Tasks works slightly different than for cases. When assigning an HR task, we compute and order the list of agents as before, but after ordering we check to see if the task has a parent case whose agent (assigned to) is in the list. If it is, we bump that agent to the top of the list regardless of agent load.
Frequently Asked Questions
It looks like the "least loaded" functionality isn't working correctly. What is wrong?
If you are on Jakarta but prior to patch 10, or on Kingston but prior to patch 8, then you are likely being affected by PRB1290209.
How can we make auto assignment apply only to cases assigned to HR Tier 1 group?
This can be solved in multiple ways. Easiest would be to add an OR clause to the condition on the BR: current.assignment_group == ‘22d52c269f221200d9011977677fcf97 (the sys id of tier 1 group). If you want to avoid hardcoding a sys id, then you could go to each of the matching rules and change the condition from “assignment group is empty” to “assignment group is HR Tier 1”.
Hello Joseph Gabriel,
So far we don't have anything given OOB by ServiceNow to handle this case, we had the same requirement to achieve this we created a simple module called Timeoff (cmn_schedule_span table) and designed process to make an entry into this module when they are going on planned leaves or sick leaves with the exception of emergency leaves(those absence should be handled by HR Manager by actively looking at the queue of HR agent who is on emergency leave and reroute them to other agents queue)
and IMPORTANTLY modified the script include "hr_AssignmentUtil" which is getting called in MATCHING RULE a bit by applying the following code (if required to implement same please copy this script after line number 270 return 0)
for (var index = 0; index < list.length; index++)
ids.push(list[index]['id']);
//the following line are added by Sushma R
//written by Sushma as a part of story STRY0012314 and STRY0012684 (only active users)
var currentDate = new GlideDateTime().toString(); //get current date and time to check if that falss between the schedule entry start and end date time
var cDate = new GlideScheduleDateTime();
var datstr=currentDate;
//convert the glide date time into schedule date time field format
var year = datstr.substring(0,4);
var month = datstr.substring(5,7);
var day = datstr.substring(8,10);
var hour = datstr.substring(11,13);
var min= datstr.substring(14,16);
var sec = datstr.substring(17,19);
var dat2comp2 = year+month+day+'T'+hour+min+sec;
for(i=0;i<=ids.length;i++){
var gr= new GlideRecord('cmn_schedule_span');
gr.addQuery("start_date_time","<=", dat2comp2);
gr.addQuery("end_date_time", ">=", dat2comp2);
gr.addQuery('user',ids[i]);
gr.query();
if(gr.next()){
var index1 = ids.indexOf(ids[i]);
ids.splice(index1,1);
}
}
return ids;
This helped us not to auto assign case who are on leave.
Hit helpful if it was and please comment if more information required in implementing this
Thanks,
Sushma R
