Case participants and routing
Routing Assignments to Case participants instead of specific users or static queues adds flexibility to Case processing. Instead of assigning work to a fixed user (for example, user@abctech), you route the Assignment to a participant role such as Supervisor or Requester. The task is automatically sent to whoever holds that role, even if that person changes during the Case life cycle. This approach supports scenarios where the responsible person is identified after Case creation.
Using participant roles also improves clarity and maintainability. Routing a Step to the Originator or Line Manager makes the design easier to understand without requiring decoding of operator IDs. This approach helps new team members interpret the process more quickly.
Pega Platform™ supports Case participants with built-in Data Models, validation, and UI behavior. You define participants once in the Case type and reuse those roles in routing configurations. Standard routing options, such as ToWorkParty, and using business logic, apply the roles consistently to create a scalable and maintainable routing design.
Roles in assignment routing
To use Case participant functionality effectively, you must understand how routing activities interact with work parties.
Routing activities such as ToWorklist, ToCreateOperator, and ToCurrentOperator route Assignments to specific users without referencing their participant role.
In contrast, routing by using ToWorkParty or ToNewWorkParty makes the routing logic role-based and easier to interpret.
- ToNewWorkParty adds the work party if it does not exist.
- ToWorkParty expects the party to be defined in advance and throws an error if it is missing.
Case participant behavior
In Pega applications, the Data-Party class provides the base functionality for case participants. Subclasses, such as Data-Party-Operator and Data-Party-Person, extend the class. Each subclass overrides key behavior to support a different participant type.
For example, the WorkPartyRetrieve activity is a polymorphic activity that runs whenever the system adds a page to the .pyWorkParty() page group. Both Data-Party-Operator and Data-Party-Person override this activity, as shown in the following figure:
In Data-Party-Operator, the activity is Final. In Data-Party-Person, the activity is not Final and supports customization. An on-change activity on the property triggers this behavior to ensure that the correct implementation runs for each participant type.
To override validation or display behavior, specialize the activity or extend the relevant party class. Scope changes carefully to avoid unintended side effects.
Case participants advanced configuration
A Work Party Rule defines all possible participants who interact with a Case. The standard Rule is pyCaseManagementDefault.
Use descriptive role names, such as Sales Agent, Line Manager, or Executive Officer. Avoid generic labels, such as Owner or Originator, which might become ambiguous as the Case progresses.
To dynamically manage participants, use the visible on entry (VOE) option for the following actions:
- Add participants to the new harness.
- Automatically add the current operator as a participant.
- Automatically add another operator as a participant based on business logic.
For automation, the CurrentOperator Data Transform adds the current operator as a participant during Case creation. You can also create custom Data Transforms, such as NewParty, to add additional participants.
Initialization of work party property values
In Pega Platform , Case participants provide a structured and reusable enhancement of traditional work parties. They support consistent design and simplify routing logic throughout the Case Lifecycle.
Before routing work to a designated Case participant, ensure that participant values are initialized.
You can initialize values by using the following methods:
- Use the visible on entry (VOE) option on the Case participant rule.
- Use Data Transforms or decision logic.
- Run the addWorkObjectParty activity.
Use addWorkObjectParty carefully if the participant already exists and is not configured as repeatable.
Proper initialization ensures that roles include the correct data (for example, pyFirstName, pyLastName, pyEmail1) so that routing, UI, Validation, and Correspondence work correctly.
Setting the work party in a Flow Action by using a Data Transform
The following table describes how to set a work party during pre-processing and post-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 |
As a best practice, always define routing for every Assignment, including the first one. This approach prevents routing issues when a Case is routed back to the initial assignment or when steps are auto-advanced because of Service-Level Agreement conditions.
Pega Platform includes the following Rules that you can use to add Case participants:
| Rule type | Rule name | Purpose |
|---|---|---|
|
Activity |
addWorkObjectParty |
Adds a participant to a Case dynamically. Recommended for initializing work party values at runtime. |
|
Activity |
PartyCreate |
Creates a new party instance. Often used with other setup activities. |
|
Activity |
removeWorkObjectParty |
Removes a participant from a Case. Useful for reassignments or cleanup. |
|
Flow |
AddPartyDetails |
Provides a guided flow to collect and configure participant details. |
|
Flow action |
Add Party |
Allows users to manually add a party during case processing by using the UI. |
These Rules support flexible and maintainable participant configuration. For automation, use Data Transforms, such as CurrentOperator or NewParty, to populate required fields, such as .pyFirstName, .pyLastName, and .pyEmail1. Use these Rules rather than directly manipulating .pyWorkParty() to avoid unintended behavior.
Note: In Pega applications, the terms Case participant, work party, and stakeholder might seem interchangeable. They refer to individuals or entities associated with a Case, whether they actively participate or receive updates. Participants can be internal users or external parties without direct system access.
In Pega Platform, participant roles are configured in App Studio on the Participants tab of a Case Type, as shown in the following figure:
For more information, see Adding Case participants to a Case Type.
For foundational guidance on configuring Case participants, see Defining Case participants.
At run time, the Utilities pane in a Case Full Page View displays Case participants in the Stakeholders widget.
Add the Stakeholders widget as a default Case utility widget in App Studio. Configure the underlying Case participants (work parties) in Dev Studio.
Although you can access the underlying View Rules in Dev Studio in advanced scenarios, use App Studio for standard configuration to remain App Studio-compliant.
For example, the Stakeholders widget can display the following participant roles:
Customer
A party role of the Person type. The role represents an external individual who receives value from the Case, such as status updates or resolution outcomes.
Interested
A party role of the Person type. The role represents an external individual who follows Case progress, but the outcome does not directly affect the individual. Unlike Followers, who must be system users, interested parties can be external and do not require system access.
Owner
A party role of the Operator type. By default, the system assigns the person who created the Case as the participant with the Owner role. Update this assignment if needed.
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?