Push routing and Pull routing
Push routing and Pull routing
The two basic types of routing are push routing and pull routing.
Push routing logic is invoked during case flow processing to determine the routing for the next assignment for the case. Push routing can create either a worklist or workbasket assignment. When routing to a worklist assignment, Pega can use multiple criteria to select the ultimate owner, such as availability (whether an operator is available or on vacation), the operator's work group, operator skills, or current workload. You can even configure routing to a substitute operator if the chosen operator is not available.
Pull routing, also known as the system-selected assignment model, occurs outside the context of a case creating an assignment. In standard portals, you can pull the next assignment to work on using Get Next Work by clicking Next Assignment at the top of the portal. It is also possible to pull an assignment to work on by selecting Look for an assignment to perform after add? within a flow rule's Process tab, Look for an assignment to perform? within a flow action rule's Action tab.
The Get Next Work feature selects the most urgent assignment from a set of assignments list. Ownership of the fetched assignment of a work queue does not occur until either the MoveToWorklist activity is called or the user submits the fetched assignment's flow action. The GetNextWork_MoveAssignmentToWorklist application settings rule must be set to true for the MoveToWorklist activity to be called.
The following image illustrates how routing activities, when to run in a case processing context, are used to achieve push routing. The image also illustrates how GetNextWork-related rules, executed in a non-case processing context, are used to achieve pull routing.
There are four main categories of Push Routing activities, as shown in the following table.
Common | Organization-Based | Decision-Based | Skills-Based |
---|---|---|---|
ToAssignedOperator |
ToWorkGroup
|
ToDecisionMap
|
ToLeveledGroup
|
The legitimate use of ToCurrentOperator
Use the ToCurrentOperator routing activity carefully. If a Change Stage action is performed that moves the case backward, the person who performs the action will become the owner of the newly created assignment. Instead, the person performing the move may want the assignment to be routed to a party associated with the case. In that situation, work party routing may be useful.
If a background process such as a Standard Agent or Advanced Agent moves a case forward to an assignment that uses ToCurrentOperator routing, this may produce an assignment routing error. The case would then be sent to the ProblemFlow to store an assignment reference to the case which would otherwise be in limbo. Such a situation can also occur when an assignment using ToCurrentOperator follows a Wait shape.
Leveraging roles in assignment routing
Routing activities (pyActivityType = ROUTE) such as ToWorklist, ToCreateOperator, and ToCurrentOperator do not specify the role of the person receiving the assignment and routes to a specific operator. Routing to a specific work party role however makes it more evident why the assignment is routed to the person who receives it. More importantly, a work party role provides a layer of abstraction to the assignment routing. This allows the same routing mechanism to be used (ToWorkParty) to assign to different operators by changing the operator assigned to perform that role.
When using ToWorklist routing, it is better to use a property name that indicates the receiver's role rather than a hard-coded Operator ID.
Party roles should also be specific to the solution and not be overly generic. In the beginning, the person who creates a case can be considered the owner. But later in the case life cycle, after being routed to multiple persons, it can become confusing as to who is the owner. You are not tied to only leveraging the Pega provided role names. Consider creating specific role names such as originator, sales agent, line manager or executive officer to provide a meaningful description for each role.
ToNewWorkParty and ToWorkParty both route an assignment to the worklist of the party specified by the PartyRole parameter. ToNewWorkParty also adds a work party for the PartyRole if it does not already exist. ToWorkParty, on the other hand, throws an error if the configured PartyRole did not exist before the assignment.
Both of the following activities use the @pickBalancedOperator() function. This function evaluates for required, desired skills, and workload of the operator.
- Work–.ToSkilledGroup
Using skill-based routing, the assignment is routed to an operator in the work group who is available with the required and desired skills. If none of the work group operators meets the criteria, the assignment is routed to the work group manager. - Work–.ToLeveledGroup
This routing activity is similar to Work-.ToSkilledGroup except that it sends an assignment to the operator within a specific work group while taking operator workload into account and assigns the work to the least busy operator who has the required skills
It is the task of the lead system architect (LSA) to determine the business the best routing techniques. Routing assignments to the "best" operator is crucial in achieving good staff utilization and high throughput.
This Topic is available in the following Module:
Want to help us improve this content?