Case participants and routing
Adding case participants (previously known as Work Parties) to case types allows for a consistent design. It can simplify the configuration of routing throughout the case life cycle. Using case participants in your solutions allows you to leverage capabilities (such as a ready to use data model, validation, UI forms, and correspondence provided in the base product), simplifying design and maintenance. This topic concentrates on forming a deeper understanding of case participant functionality and routing configuration to aid the developer in fully leveraging this functionality.
Case participant behavior
Most of the existing code for case participants is contained in the Data-Party class, which 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 used to define the work party. For example, work party initialization, validation, and the display differ between work parties constructed from the Data-Party-Operator class compared to those constructed from the Data-Party-Person class. You are encouraged 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. This activity is overridden within the Data-Party-Operator and Data-Party-Person derived classes.
The WorkPartyRetrieve activity is significant because it is invoked every time a page is added to the .pyWorkParty() pages embedded on 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.
It may be required to override the default behavior of some aspect 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 the scope of the changes is made correctly to prevent unintended behavior change.
Case participants advanced configuration
A Work Party rule defines a contract that defines the possible case participants which can be used in the case.
Define case participants for the case in the standard work parties' 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 can be subject to change and may not intuitively describe the party’s role with respect to the case.
You can use the visible on entry (VOE) option to add work parties when a case is created. VOE allows you to:
- Enable the user to add work parties in the New harness
- Automatically add the current operator as a work party
- Automatically add a different operator as a work party
Use the data transform CurrentOperator in the work parties' rule to add the current operator as a Case Participant when a case is created. You can create custom data transforms to add other work parties when a case is created.
Create or customize existing data transform with the intended logic for a solution (please refer to existing data transform rules).
Case participants and App Studio
In App Studio, you can add participants by using the Settings tab in a case type.
In the Participant configuration pane, click Add Participant and enter a unique title in the Role name field. This role indicates the relationship of the participant in the case type.
If the participant is an application user, the systems adds the user as an Operator type work party.
In the Map participant section, you can associate the participant as the current user or a reporting manager of the current user. Pega creates a data transform. For example, in the BookEvent case type, if the role name is Manager, then Pega creates a data transform named BookEvent_Manager.
If the participant is a non-application user, the system adds the user as a Person type work party.
The following table illustrates the difference between case participants added by App Studio and Dev Studio.
|App Studio||Dev Studio|
Initialization of work party property values
Before routing to a designated case participant, you must initialize the work party property values. You can initialize the values at the time of case creation by using the VOE option on the Work Parties rule, or you can perform the initialization dynamically during case processing. When dynamically setting the work party values, leverage the addWorkObjectParty activity. Leveraging the activity also allows you to specify a data transform to initialize the values. Take caution while using this activity if the case participant already exists and is not declared as repeatable.
|On Perform (Pre-Processing)||On Submit (Post-Processing)|
WHEN @PageExists(".pyWorkParty("+param.PartyRole+ ")") = false
WHEN @PageExists(".pyWorkParty("+param.PartyRole+ ")")
In NewParty data transform set values to these required fields
.pyFirstName, .pyLastName, .pyEmail1
In CurrentOperator data transform set values to these required fields
.pyFirstName, .pyLastName, .pyEmail
Do not attempt to initialize and set the values on the work party page directly as this may 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).