Skip to main content
Verify the version tags to ensure you are consuming the intended content or, complete the latest version.

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.

Work Party Retrieve
This figure shows that the Data-Party WorkPartyRetrieve activity is specialized by the Data-Party-Operator class and by the Data-Party-Person class. The WorkPartyRetrieve activity in the Data-Party-Operator class is Final. The WorkPartyRetrieve activity in the Data-Party-Person class can be overridden.
 

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).

CurrentOperator, NewParty

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.

Participant configuration
The Settings tab for a case type displayed in the Case Design has a Participants menu item. This view shows the panel that is displayed when the Add participant link is clicked.
 

The following table illustrates the difference between case participants added by App Studio and Dev Studio.

App Studio Dev Studio
  • Participants are added from the case type rule
  • Participants are added from the case type rule.
  • Participants are added using pyCaseManagementDefault(Rule-Obj-WorkParties) rule
  • Case participants can be added as only the following types:
    • Operator (Data-Party-Operator)
    • Person (Data-Party-Person)
  • Case participants can be added as the following types:
    • Company (Data-Party-Com)
    • Person (Data-Party-Person)
    • Government (Data-Party-Gov)
    • Operator (Data-Party-Operator)
    • Non-Profit (Data-Party-Org)
  • If the participants are added as application user type (Data-Party-Operator), they can be mapped as Reporting Manager or Current User
  • Pega Platform™ creates a data transform automatically and the logic is embedded
  • While adding participants, use existing or customized data transform

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)

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 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).


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice