The Guidewire Assignment Engine provides automated assignment of activities, exposures, and claims controlled
by rules specified in the Guidewire Rules Engine. Several different assignment algorithms are available - each
is listed below.
User Attribute Assignment
The solution to the problem has a few facets which are described briefly here and then in more detail in the sections
below. First, assignment logic should be able to figure out which people in a group (or groups) is “qualified” to
handle an assignment based on some customer-defined criteria. Based on examples of this criteria, we’ll also have to
enhance the data we keep about users to support custom, multi-valued attributes about users. Second, supervisors need
to be able to indicate that some users are out-of-the-office (e.g. vacation) or handling a lighter load than other
users. This is similar to our existing “load factor” concept, but not the same. Third, once we’ve gotten a list of
“qualified users”, we need to select which of those users to give the assignment to. For a variety of reasons, we need
something more sophisticated than our existing “round robin within a group” algorithm for this.
User attributes
Companies want to associate users with various attributes to support assignment logic (and potentially other purposes).
Here are some use cases:
Customer accounts – to support adjusters associated with specific customers for large commercial accounts
Expertise – indicate that certain adjusters have special experience or skills which are needed for certain types
of claims.
States – It is common for certain adjusters to specialize in claims for certain states since the laws differ by
state. (This would be an alternative to having groups for each state and using AssignByRegion logic to choose the
correct group.)
This information is stored in the cc_userattributes table. Each attribute would consist of:
AttributeType: Indicates “Account” or “Expertise” to classify what kind of attribute this is. (This should be
based on a typelist.)
AttributeSubtype: An optional typelist which is filtered on the AttributeType field. For example, if the
AttributeType equaled "Language", then the Attribute would have "French", "Spanish", "English", etc for possible values.
Value: An optional integer value that can be used to assign a "score" to a particular attribute. For example,
the "Language" attribute above could be further categorized by grading users' fluency on a customer-defined scale of
1-4.
Criteria-based qualification
User attribute assignment is controlled via the Rules Engine. The syntax of the user attribute assignment rule is as
follows: assignToUserByAttribute(boolean searchSubGroups, criteria(boolean test1, boolean test2, boolean test3, etc)).
Each test is a boolean expression that is added to the user search query. The available root objects for each
expression are User and or UserAttribute. UserAttribute has two methods:
boolean hasAttribute(AttributeType type, AttributeSubtype subtype) returns a flag indicating whether or not a user
has the specified attribute.
int getAttribute(AttributeType type, AttributeSubtype subtype) returns the value of the specified attribute for a
given user.
For example, a more complex claim with injuries in Texas might be assigned to
a higher-skilled adjuster who works on Texas claims. When calling the assignment action in the rule engine, the rule
writer would want to indicate something like:
assignToUserByAttribute(true, criteria(“User.skillLevel>=3", UserAttribute.hasAttribute(‘State’, ‘TX’)”, … )
The idea is for the assignment action to take a criteria string which can be parsed by the scripting engine to create
a query. Ideally, the method would then find all the users that match the criteria within either a) the current group
or b) the current group and all its children. This list of people (with some more filtering described below) would
then form the list of “qualified users” to choose among.
User availability (load factor)
In Claim Center 1.0, we used load factors for 2 purposes: to give a user a lower share of the load (to take into
account part time workers, new users, etc.) and to indicate that a person should receive any assignments (by setting
the LF to 0) when the person is out of the office, for example. These load factors were used at the group level and
only by round robin algorithms.
The User Attribute assignment algorithm, however, selects a user across potentially multiple groups. As a result, more
than one load factor may be found for a given user. The load factor is resolved using the following rules:
Number of load factors found
Load Factor to use
0
1 (if load factors haven't been set up, then assume all users are fully active)
1
the given load factor
0
the sum of all the load factors, capped at 1
In addition to the load factor, the user's current workload needs to be included in the availability calculation. To
that end, a TLA (Time since Last Assignment) number is calculated, which is the number of minutes since the user was
assigned an item of the same type as the current item. In other words, if an Activity is being assigned, the last
Activity the user was assigned forms the basis of the TLA number.
The user's availability, then is the TLA number multiplied by the calculated Load Factor. For example, if the user
was assigned a Claim one day ago, and has a load factor of .8, his availability would be:
60 minutes/hour * 24 hours/day * 1 day * .8 = 1152
The user who satisfies the criteria specified in the rule action, and who has the highest availability number, is
assigned the item.
Exceptions
The Assignment Engine deals with the following cases where no assignment is possible:
There are no “qualified” users – return that the assignment action did not succeed
All qualified users have zero load factor – return that the assignment action did not succeed