Next topic

Case routing

In Pega Platform™, there are two basic types of routing for work assignments: push routing and pull routing.

The system uses push routing logic during case flow processing to determine the routing for the next assignment for the case. Push routing creates either a worklist or workbasket assignment. When routing to a worklist assignment, Pega Platform can use multiple criteria to select the ultimate owner, such as user availability, the user's work group, user's skills, or current workload. Routing can even be configured to a substitute user if the 'best' user 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 that you want to work on by 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? on the Process tab of a flow rule, and Look for an assignment to perform? on the Action tab of a flow action rule.

The Get Next Work feature selects the most urgent assignment from a list of assignments. Ownership of an assignment fetched from a work queue is not determined until either the system calls the MoveToWorklist activity, or the user submits the flow action of the fetched assignment. The application settings rule of GetNextWork_MoveAssignmentToWorklist must be set to True for the system to call the MoveToWorklist activity.

Note: After a successful run of the Assign-.GetNextWorkCriteria decision tree, the system calls MoveToWorklist from the pzOpenAssignmentForGetNextWork function

The following figure illustrates how routing activities, when run in a case processing context, can achieve push routing. The figure also illustrates how GetNextWork-related rules, run in a non-case processing context, can achieve pull routing. Push routing occurs in the case processing context, where a case creates a new assignment and decides which person or queue owns that assignment. Pull routing occurs outside a case processing context. Users then ask the system to choose the best assignment for them to work on. The work is, in effect, routed to that person.

There are four main categories of push routing activities, as shown in the following table:

Category	Activities
Common	ToAssignedOperator ToCreateOperator ToCurrentOperator ToWorkParty ToNewWorkParty ToWorkbasket ToWorklist
Organization-based	ToWorkGroup ToWorkGroupManager ToOrgUnitManager
Decision-based	ToDecisionMap ToDecisionTable ToDecisionTree
Skills-based	ToLeveledGroup ToSkilledGroup ToSkilledWorkbasket

ToCurrentOperator

Use the ToCurrentOperator routing activity carefully. If a Change Stage action that moves the case backward occurs, the user who performs the action becomes the owner of the newly created assignment. Instead, the user who performs the move might want the assignment to route to a party that is associated with the case. In that situation, work party routing is helpful.

An assignment routing error might occur if a background process, such as a standard agent or advanced agent, moves a case forward to an assignment that uses ToCurrentOperator routing. The system sends the case to the ProblemFlow to store an assignment reference to the case, which otherwise remains idle. Such a situation can also occur when an assignment that uses ToCurrentOperator follows a Wait shape.

Pull routing by external application

Long waiting services eventually block progress for hours and cause transaction and connection timeouts when being called synchronously. As a best practice, asynchronously calling long waiting services is an advisable design pattern.

Consider a use case for home and auto loan processing. As part of the process, the servicer of the loan needs the credit information of the applicant to determine the applicant's eligibility for the loan, their interest percentage, and existing liabilities. Credit bureaus maintain the latest as-on-date credit information. A request for the latest credit information takes three-to-seven business days to process. For long waiting periods like this, you should use an external task assignment pattern to solve the purpose.

The following figure shows an example flow of how pull routing is implemented in a credit card application:

The workflow request for credit information is sent to the credit bureau. Once the credit information is processed and available to consume, an API request is received by the workflow. After that, the workflow proceeds again. In high-availability systems, you can use a Kafka (Real-time Data flow) /JMS (Java Message Service) (Listener) message that is sent from the workflow to an API call. For API requests to the workflow in this case, you could use an out-of-the-box Pega REST API call. If there are additional business needs, you can also build a custom API implementation.

You can solve the following use cases by taking a similar approach:

A SWIFT transaction between banks requires confirmation from the destination bank for the workflow to proceed after the source bank initiates the transaction.

Address correction workflows involve the central system of record (SOR) of an organization maintaining the address of a customer, and the customer requesting a correction to their address. The workflow waits until the central system confirms the correction, and then the updated information propagates to other impacted systems.
A network hospital onboarded to an insurance provider needs to confirm with the payer all of the hospitalization details and medical evidence for the claim that the insurer raises.

This approach provides a temporal decoupling with a dedicated messaging or an API interface, and better scaling with parallel processing.

Prioritization and routing of case work

Predictive analytics can be used to optimize case flow by predicting the outcome of cases. For instance, if the predicted risk of case escalation is high, you can automate a decision to prioritize the case. Conversely, if an incoming case has minimal risk, you can configure a decision to process the case automatically.

As an example, U+ Insurance utilizes Pega Platform for case management. When an incoming car insurance claim is received, the system routes it to a user who approves or rejects the claim to resolve the case. If the claim misses the deadline for regular processing, the system escalates the case to an expert. Claims that involve casualties are always routed to an expert as a precaution, even if they are not complex. However, this means that experts may spend valuable time on simple claims. To optimize the process, you can prioritize a claim by predicting the likelihood that a case will be resolved before the deadline in the regular workflow. If the likelihood is low, the claim should be routed to an expert regardless of the cause of complexity. This optimization requires a data scientist to create a case management prediction that calculates a propensity value for case complexity. The adaptive model learns from previous cases and automatically activates predictors that perform above a threshold, and deactivates predictors when their performance drops over time.

The output of a prediction can be used in various ways in the case workflow by utilizing the condition builder. You can route assignments, branch processes, or validate information based on the prediction output. For more information, refer to the Predicting case outcomes documentation.

Check your knowledge with the following interaction: