Case participants and routing
Adding case participants to case types in your Pega Platform™ application allows for a consistent design, and can simplify the configuration of routing throughout the case life cycle. Using case participants in your solutions, you can access features (such as ready-to-use data models, validation, UI forms, and correspondence) that simplify the design and maintenance of your application. Gain a deeper understanding of case participant functionality and routing configuration to help the development team to fully benefit from this functionality.
Case participant behavior
In Pega Platform, the Data-Party class contains most of the existing code for case participants and provides the base functionality and orchestration for rules in derived classes. Several classes extend Data-Party, such as Data-Party-Operator, which overrides the base functionality. It is important to understand this polymorphic behavior because the behavior changes depending on the class that you use to define the work party.
Work party initialization, validation, and display differ between work parties constructed from the Data-Party-Operator class compared to those constructed from the Data-Party-Person class. It is a good idea to review and compare the rules provided in the Data-Party class and subclasses to appreciate the base functionality and specialization provided. An example of a polymorphic rule is WorkPartyRetrieve activity, and this activity is overridden in the Data-Party-Operator and Data-Party-Person derived classes, as shown in the following figure:
The WorkPartyRetrieve activity is significant because the system invokes the activity with each addition of a page to the .pyWorkParty() pages that are embedded in the case. The .pyWorkParty() page group stores the individual parties added to the case. The property definition contains an on-change activity that ultimately invokes the WorkPartyRetrieve activity.
You might need to override the default behavior of some aspects of the work parties, such as validation or display. You can perform the override either through ruleset specialization or by extending the work party class and overriding the required rules. If this is required, ensure that you make the scope of the changes correctly to prevent unintended behavior change.
Case participants advanced configuration
A work party rule defines a contract that defines the possible case participants who can work in the case.
Define case participants for the case in the standard work party rule pyCaseManagementDefault. Use meaningful party role names to enhance application maintainability. Avoid generic names such as Owner and Originator. Generic, non-descriptive role names such as Owner are subject to change and might not intuitively describe the role of the participant role for the case.
You can use the visible on entry (VOE) option to add work parties after the creation of a case. 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 data transform CurrentOperator in the work party rule to add the current user as a case participant on the creation of a case. You can create custom data transforms to add other work parties when a case is created.
You can create or customize an existing data transform with the intended logic for a solution (for example, by referring to existing data transform rules such as CurrentOperator, NewParty).
Initialization of work party property values
Before routing to a designated case participant, you 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. With this activity, you can also specify a data transform with which to initialize the values. Take caution when using this activity if the case participant already exists and is not declared repeatable. An example of how you set the work party in a flow action both before and after processing is presented in the following table:
| 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 |
Do not attempt to initialize and set 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 advanced automatically 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:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?