Case participants and routing
Adding case participants to Case Types in Pega Platform™ allows for a consistent design and simplifies routing configuration throughout the case life cycle. By using case participants in your solutions, you can access features such as ready-to-use data models, validation, UI forms, and correspondence, to simplify application design and maintenance. To fully benefit from this functionality, gain a deeper understanding of case participant functionality and routing configuration to help the development team.
Roles in assignment routing
Routing activities (pyActivityType = ROUTE) such as ToWorklist, ToCreateOperator, and ToCurrentOperator do not specify the role of the user who receives the assignment and simply route to a specific user. However, routing to a specific work party role makes it more obvious as to why the assignment goes to the user who receives it. In addition, a work party role provides a layer of abstraction to the assignment routing. This method allows the system to use the same routing mechanism (ToWorkParty) to assign work to different users, by changing the user who is assigned to perform that role.
When using ToWorklist routing, use a property name that indicates the role of the recipient rather than a hard-coded Operator ID.
As a best practice, ensure that party roles are specific to the solution and are not overly generic. In the beginning, the user who creates a case can be considered the owner. But later in the case life cycle, after routing to multiple persons, there might be confusion as to who the owner is. You can then create role names beyond the names that Pega Platform provides out of the box. 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, returns 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, preferable skills, and the workload of the operator.
-
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 user workload into account, and assigns the work to the least busy user who has the required skills. -
Work-.ToSkilledGroup
Using skill-based routing, the system routes the assignment to a user in the work group who is available with the required and preferred skills. If none of the work group users meets the criteria, the system routes the assignment to the work group manager.
It is the task of the Lead System Architect (LSA) to determine the best routing techniques for the business. Routing assignments to the 'best' user is crucial in achieving good staff utilization and high throughput.
Case participant behavior
In Pega applications, the Data-Party class contains the base functionality and orchestration for rules in derived classes that handle case participants. Data-Party-Operator is one of the classes that extends Data-Party and overrides the base functionality. Understand this polymorphic behavior because the behavior changes depending on the class that defines the work party.
Work party initialization, validation, and display differ between work parties constructed from Data-Party-Operator and Data-Party-Person classes. Review and compare the rules provided in the Data-Party class and subclasses to understand the base functionality and specialization provided. For example, WorkPartyRetrieve activity is a polymorphic rule that is overridden in Data-Party-Operator and Data-Party-Person derived classes, as shown in the following figure:
Pega invokes the WorkPartyRetrieve activity each time a page is added to the .pyWorkParty() page group that stores the parties added to the case. The on-change activity in the property definition invokes the WorkPartyRetrieve activity.
To override the default behavior of some aspects of work parties, like validation or display, you can either specialize the ruleset or extend the work party class and override the necessary rules. Ensure that you scope the changes correctly to prevent unintended behavior changes.
Case participants advanced configuration
A work party rule defines the possible case participants who can work on the case.
You define case participants for the case in the standard work party rule, pyCaseManagementDefault. Use descriptive role names to enhance application maintainability, and avoid generic names like Owner and Originator, which might not intuitively describe the role of the participant for the case.
You can use the visible on entry (VOE) option to add work parties after the case is created. With VOE, you can:
-
Enable the user to add work parties in the new harness.
-
Automatically add the current user as a work party.
-
Automatically add a different user as a work party.
Use the CurrentOperator data transform in the work party rule to add the current user as a case participant when the case is created. You can create custom data transforms to add other work parties when a case is created.
Create or customize an existing data transform with the intended logic for a solution. For example, you can refer to existing data transform rules such as CurrentOperator or NewParty.
Initialization of work party property values
Before routing to a designated case participant, initialize the property values of the work party. You can initialize the values at the time of case creation by using the VOE option on the work party rule, or you can perform the initialization dynamically during case processing. When dynamically setting the work party values, use the addWorkObjectParty activity. You can also specify a data transform to initialize the values. Be cautious when using this activity if the case participant already exists and is not declared repeatable. The following table presents an example of how to set the work party in a flow action both before and after processing:
| On Perform (Pre-Processing) | On Submit (Post-Processing) |
|---|---|
|
SET Param.PartyClass=”Data-Party-Person” SET Param.PartyModel=“NewParty” WHEN @PageExists(".pyWorkParty("+param.PartyRole+ ")") = false SET PARAM. Success=@pxExecuteAnActivity(“Primary”,“addWorkObjectParty”) |
SET Param.PartyClass=”Data-Party-Operator” SETParam.PartyModel=“CurrentOperator” WHEN @PageExists(".pyWorkParty("+param.PartyRole+ ")") REMOVE .pyWorkParty(param.PartyRole) SET PARAM. Success= @pxExecuteAnActivity(“Primary”,“addWorkObjectParty”) |
|
In the NewParty data transform, set the values for the following required fields: .pyFirstName, .pyLastName, .pyEmail1 |
In the CurrentOperator data transform, set the values for the following required fields: .pyFirstName, .pyLastName, .pyEmail |
Avoid initializing and setting the values on the work party page directly, as this can cause unintended results.
As a best practice, define routing for every assignment, including the first assignment. Doing so prevents routing issues if the case is routed back to the first assignment during case processing or if the previous step is automatically advanced through a service-level agreement (SLA).
Pega Platform comes with the following out-of-the-box rules that you can use to add case participants:
| Rule type | Rule name |
|---|---|
|
Activity |
addWorkObjectParty |
|
Activity |
PartyCreate |
|
Activity |
removeWorkObjectParty |
|
Flow |
AddPartyDetails |
|
Flow action |
Add Party |
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?