You are here: Advanced > Use case scenarios - customizing with business rules > Using rules for automatic assignment and suggestions for groups
Using rules for automatic assignment and suggestions for groups
When you create process driven records - such as requests or incidents - in Service Management, it is often desirable to assign them automatically to a specific group, based on information in the record. In other cases it may not be possible to assign the record to a specific group, but instead the system can provide the agent with a list of suggestions, again based on information in the record. You can achieve both using business rules.
There are two rule types commonly used to automatically set the initial group in a record:
-
Set field
-
Set field based on routing definition
Both are used in the After change section of the rules.
Note The most common groups seen in automatic assignment cases are Service Desk Group and Expert Group (for requests and incidents). However, you can use the examples here for any group field in a record; simply specify the field name when defining the rule.
Use case number 1
When creating a new IT Service Request, automatically set the service desk group to the 1st level support of the specified actual service.
To implement this use case, you create a Set field rule in the IT Service Request workflow. You can use the Set field rule to set a field to a specific value, or to the result of an expression. For example, to implement automatic assignment, you can set the desired group to a specific value, or to a value determined by an expression. That expression might define a group based on another value in the record, such as the service.
You create the following Set field rule in the Classification metaphase of IT Service Request, in the After change section:
If ${entity.ServiceDeskGroup == null} Set Service desk group to ${entity.RegisteredForActualService.SupportLevel1Group}
The condition in this rule checks to see whether Service desk group already has a value, because you do not want to overwrite a value that the agent has entered. If there is no value, it specifies that Service desk group should be populated with the value of the 1st level support field in the service to which the request relates.
Use case number 2
When creating a new IT Support Request, automatically set the service desk group according to a routing definition. The routing definition allows a group to be selected based on a combination of a service, location, and organization.
There are two parts to the implementation of this use case:
-
Creating the routing definition
-
Creating the business rule
Routing definition
Here is an example of a routing definition:
In this example, the routing definition selects a group based on a service and a location.
Business rule
You create the following Set field rule in the Classification metaphase of IT Support Request, in the After change section:
If ${entity.ServiceDeskGroup == null} Set Service desk group based on routing definition Service based RD with Actual Services: entity.RegisteredForActualService.Id Locations: entity.RequestedByPerson.CurrentLocation.Id
The condition in this rule checks to see whether Service desk group already has a value, because you do not want to overwrite a value that the agent has entered. If there is no value, it specifies that Service desk group should be populated with the value determined by the routing definition.
In this use case, the location of the Requested by person is used.
Use case number 3
When an end user creates a request in the Service Portal, set Service desk group based on the following:
-
For a specified offering or incident model, or change model, set the service desk group based on one of:
-
A specified routing definition, or
-
The 1st level support field in the associated service definition, or
-
A specified group
-
-
Or, if the actual service is defined, then set the service desk group based on:
-
A specified routing definition, or
-
The 1st level support field in the actual service record, or
-
A specified group
-
-
Or, if the service is not defined, but a location is part of a specific geography, then set the service desk group based on a different location based routing definition
-
Or set the group to a specific default group
There are two parts to the implementation of this use case:
-
Creating the business rules for each offering
-
Creating the general business rules for the Request record type
Business rules for offerings
To implement this use case, you must add the relevant assignment rules to each Service Offering, Incident Model, and Change Model record that has specific rules. You enter these rules:
-
In the Default values tab, if setting to a specific value, or
-
In the Rules tab, if using a routing definition
You can set rules to run before or after the general record business rules. For the present use case, you must run the offering and model rules before the general ones.
Business rules for the Request record type
The remaining logic is in the general record rules. In this case the request record rules, for example in the Request > IT Support > Classification > Classify phase. For each rule the current value of the group field in question (Service desk group in our case) is checked to see if it is still blank before attempting to supply a value.
With these rules our initial logic is now met. The correct group is set only if the current field has not already been filled in. Using this method, any number of automatic assignment rules may be defined in order to follow the assignment logic for any implementation.
Use case number 4
In some situations it may be necessary to pass a particular record between multiple groups. Instead of relying on the agent to pick the correct entry from the entire list of groups, we want to suggest one or more groups to choose from. There are two rule types that are useful for this purpose, both of which should be used in the Rendering forms section of the rules:
-
Define suggested values based on filter
-
Define suggested values based on routing definition
An important feature to note is that multiple rules can be configured for the same field, resulting in multiple suggestions being shown to the agent when entering that field. Since each suggestion may be labeled differently, this can be a valuable tool to assist the Agent in selecting the right group.
Similar to the automatic assignment, these rules may be placed either in the general record, or in the associated offering or model record, as appropriate. When the agent selects a group, all suggestions (from both the general and associated rules) are displayed.
Define suggested values based on filter
expression. For this example, we will create a total of three rules that will display:
● The 1st level support of the associated Service (if one is specified)
● A hard-coded list of Service Desks if there is no 1st level support (or no Service specified)
● The 2nd and 3rd level support of the associated Service (if one is specified)
● A list of all groups
The actual rules needed are:
When an agent selects Service desk group, and the service has a 1st level support, the following is displayed:
If the actual service has no 1st level support, this is displayed:
Define suggested values based on routing definition
This rule has the same result of displaying the suggested groups to the agent, but instead of a simple filter a routing definition is used. Identical to the Set field based on routing definition rule, a combination of Service, Location, and Organization may be used to dynamically select the suggested groups. The groups that are displayed come from the combination of the default group used in the set field rule, and any suggested groups that have been defined. Note that each node of the routing definition displays the number of groups, if any, that will be used as suggestions. To see the actual groups you must edit the node.
The actual rule is as follows:
This rule displays the suggested groups in a Location routing section. This rule could be included with the previous rules to give the agent multiple suggestion options. However, it is recommended to keep the number of different suggestion rules to the minimum needed, to avoid the risk of confusing the agent.
