Workparties – Usage and Configurations in Pega

In this blog article, we will learn about Workparty or case participants in Pega.

Take any Pega case as an example. The case normally has a lifecycle with different stages, processes and steps. The case can progress through different statuses during its life cycle. During the case lifeccyle, there can be different participants to the case.

You can call Case participants as the interested stakeholders.

Let’s take the example of Mortgage request with ABC bank. ABC bank decided to use Pega application to service the customers.

Now, let’s say you are in need of house mortgage and made an application with the bank. At the back end, ABC bank created a Mortgage request case for your application.

Now list me the people who can be interest in the Mortgage request case?

Obviously, you will be more interested in to know your Mortgage application status 🙂

1. Customer (you)
2. Bank employees (Case worker and Case manager), who can help with the Mortgage application.

Now, we can call both of them as Workparties/Case Participants / Stakeholders for the case.

By capturing the workparty details within the case, we can effectively route the case or notify the Workparties about the case details. You can do a lot of things with the Workparty details 😊

Okay now the next question is how do we add the case participants / work parties with the case?

— Going forward we will use only workparty name 😊—-

To add a work party, of course, you need the work party details, like the contact details.

In our above request, how to capture the work party details of Customer, Case Manager and Case Worker?

Customer details can be captured from the collect customer information screens.

Case Worker and Case Manager (reporting manager of case worker) can be added automatically based on the case worker who gets assigned/creates the Mortgage request case.

Normally when you want to add some data with the case, we can easily append the data as an embedded page or pagelist within the pyWorkPage. Adding this can be easily done by creating some activity or data transform, but… Pega wants to make this simple.

They provide a dedicated rule configuration – Workparty through which you can configure the interested stakeholders with the case.

 What is a workparty?

– Workparty is a rule type which you can configure to list the people who are interested in the case life cycle.

– When a new case is created, Pega uses the Workparty configuration and adds the interested people with the new Mortgage request case embedded into the OOTB Page group property – pyWorkParty

– Workparty rule comes under the process category.

How do we create and configure a Workparty?

The best way to create a Workparty rule is to use the Case designer and configure the case participants.

Step 1: Open the Mortgage request case type and switch to the Settings tab.

There you can find the Participants configuration.

You see by default, there are three participants added to the case. It means when you create a new case, Pega by default configured the case participants in a low code way and technically Pega creates a work party rule at the backend.

Step 2: Go to Records -> Process -> Work Parties

There you can find the already created work party rules. You find one in the Mortgage class.

Click and open the work party rule to check its configuration.

Step 3: Verify and Update the Workparty configuration if needed.

What are the configurations in the Workparty rule?

Work party rule has a single main tab.

Valid Parties

List of Valid Parties

List of valid parties – Specify the different work party roles here.

Party Label – Provides a unique label to the party role.

Role – Provides a valid identifier. It can be the same the as party label.

Party class – Provides an existing class or new class inherit from Data-Party.

You may get a question, “Why the class should inherit from Data-Party?“

You can see the picture shown below.

There are a lot of  OOTB functionality supporting rules in Data-Party class. It is wise to use the work party classes to inherit from Data-Party class so that it can reuse the OOTB workparty rules.

Pega provides 5 Data-Party concrete classes.

The most commonly used Data-Party classes are

1. Data-Party-Operator – If a Pega operator is one of the workparties of the case.
2. Data-Party-Person – If a non-pega person is one of the workparties of the case.

The other work party classes are

• Data-Party-Com, Data-Party-Org, Data-Party-Gov corresponds to Company, Organization or government entities. If these act as workparty for a case, then you can use these specialized work party classes.

You see the default workparty included the commonly used work party classes.

Party prompt – This is a label kind of field to display near the party. This is mainly used in distinguishing roles in user work form.

Data transform – Obviously, we know this is used to set values. But, “What values?“

I would say, “Workparties that get embedded with the case, should contain their contact details“.

This data transform is able to set those details.

Pega provides sample data transform – CurrentOperator, NewParty which can be easily extended.

You can set all the contact details here like email address, phone number.

We will extend and use those in our tutorial 😊

VOE? – Visible on entry

On checking this checkbox, the Data transform will get triggered at creation and uses the data transform to populate the work party details..

required? – By checking this, you can make the party role as required always, which can be used for validation.

List parties that may repeat:

Some party role can contain more than one people. For example, say I have a party role as Approvers.

Many people can potentially qualify as approvers for the case. So I can make Approvers role as repeatable.

Okay now let’s revisit our business requirement

For our Mortgage request, we can have three participants – Customer, Case Worker, Case Manager.

Let’s implement this for the Mortgage request case type

Step 1: Update the Party label and Role

Open the Mortgage work party rule and update the party roles as shown below

Step 2: Update the right party class.

For our Usecase, Case manager and Case worker are operators in Pega and belong to Party class of Data-Party-Operator.

Customer is not a Pega operator and so they will be of Party class – Data-Party-Person

Step 3: Populate the Workparty details.

Customer details cannot be populated at the time of creation as we will be collecting the Customer details only at the Create stage collect information.

Case Manager and Case Worker can be easily populated at the time of creation.

For Case worker, it is very easy. We can just use the Data transform – CurrentOperator.

For Case Manager, we can create a new Data transform and set the manager details, who is the reporting manager of Case worker.

You see the CurrentOperator Data transform which uses the pxRequestor.pyUserIdentifier to populate the pyWorkPartyUri

We can Save-as this data transform and create a new data transform – InitializeCaseManager and set the pyWorkPartyUri as shown below.

Now update the Case worker and Case manager role as shown below.

I also updated my current operator pyReportTo as administrator@pega.com for testing purpose.

Step 4: Add the Visible on entry (VOE) checkbox on Case Manager and Case work party roles.

We are done with configuring the work party rule. Time to test.

How to test the work party creation?

Step 1: Start your tracer and create a new Mortgage request case.

Step 2: Pause your tracer and open the clipboard first. Check the pyWorkPage.pyWorkParty (page group property)

You already see pyWorkParty(CaseWorker), my operator details and pyWorkParty(CaseManager), my ReportTo Manager details are populated as workparty with the case.

These workparty details persist throughout the case lifecycle and can be used anytime.

Step 3: Now, let’s check the tracer and see  how automatically embedded this pyWorkParty details

You see from the Tracer steps, createWorkPage activity Calls PartyNewSetup activity

PartyNewSetup activity is responsible for adding the new party details based on the configuration in the work party rule.

In the below picture, you can clearly see that Java code makes use of the VoE? Checkbox and add the new Workparties with the case.

Now a small exercise, how can we add the Customer Workparty to the case?

Hint:

Step 1: Collect the customer details in embedded page form – pyWorkPage.CustomerDetails.

Step 2: Create a new data transform in Data-Party-Person class and copy the details from Primary.CustomerDetails contact information. Add the data transform in the Customer Party role.

Now this needs to be triggered.

Step 3: After collecting the customer information, you can use the utility activity áddWorkObjectParty’ from Work-class. Make sure to pass the right work party role that needs to be added.

Step 4: Now if you test it out, then the Customer work party should be added within the case 😊

Okay a final thing to know.

Where can we use these work party details?

Mainly workparty details are used for two things

1. Notification or sending emails
2. When you use Send email shapes or step, you can configure to send the email to case Participants/Workparties

In flow rule assignment shape, advanced configuration you can use OOTB notify activity ‘NotifyParty’ to send email to Workparty.

Routing cases to Workparties

In the same assignment shape, you can configure custom routing to route the case to Workparty role

Hope you got the basics.

Simply saying, “Workparty is a rule to save the contact information of the parties who are interested in the work item“.

One final thing, by default the Workparties are declaratively indexed into their own dedicated table.

OOTB Declare Index name – PartyURI

 And the Index class is mapped to the OOTB Index database table – pc_index_workparty table.

If you are interested in knowing more, you can visit the Declare Index article with Workparty as an example.