In this post, we will see how to configure a workparty in Pega.
Every case/work item has a life cycle starting from creation to resolving the case.
Imagine Amazon website.
You ordered a product. At the back end, Amazon has created a Purchase request case for your product.
Now list me the people who can be interest in the purchase request case.
Obviously, you will be more interested in getting the tracking details 🙂
- Customer (you)
- Dealer – The product owner
Now, I can call both of them as workparties for the case.
Workparties can be notified using OOTB notify functionalities.
Also think for each case, work parties will be different. Yes the customer and the dealer may vary based on the product.
Hope you get the basics.
What is a workparty?
- Workparty is a rule type which can list the people who are interested in the case life cycle.
- You can add the parties in workparty rule and the parties get tagged to the case.
How do we configure a workparty?
- Workparty comes under process category.
Step 1: Create a new workparty.
Note: To add a workparty for a flow/process, create a rule ‘Default’ in the workclass.
Step 2: Configure the workparty rule form.
Work party rule has a single main tab.
List of valid parties – Specify the different work party roles here.
Party Label – Provides a unique name to the party role.
Role – Provides a valid identifier. It can be 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.
Various OOTB functionality supporting rules are in Data-Party class. So we need to make sure our parties make use of these functionalities.
Pega provides 5 Data-Party concrete classes.
You can use these existing classes.
Party prompt – This is a label kind of field to display near 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 attached with the work item, should contain their contact details“.
This data transform is able to set those details.
Pega provides sample data transform – CurrentOperator, NewParty which can be extended.
You can set all the contact details here like email address, phone number.
We will see later, how these values appear with work item in runtime.
VOE? – Visible on entry
On checking this checkbox, a user form – gets displayed to the user, when they create a case. Here manually user can enter the party details.
required? – By checking this, you can make the party role as required always.
List parties that may repeat:
- Some party role can contain more than one people. For example, say I have a party role as interested.
- Many people can be interested in that workitem. So I can make Interested role as repeatable.
Where do we configure a workparty rule?
- Flow rule – process tab.
You can specify a workparty rule here. If this rule is blank at runtime of the flow, then Pega checks the Workparty named ‘Default’ in the class path. If found, then Pega adds the workparty to the case.
- Case – Settings tab.
Click on the parties and add the parties list on the right hand side.
When you save the case type, Pega creates a workparty named ‘pyCaseManagementDefault’ in the work class.
Let us see an example using Service Request case type.
Prerequisite – You add workparty for the case type as shown above.
Step 1: Update the workparty rule, ‘pyCaseManagementDefault’ in the case workclass.
Step 2: Configure the workparty ruleform.
Add three party roles – Customer, Agent & Interested with Interested repeatable.
Add data transform – AddParty. Make VOE & Required as mandatory for Customer party role.
Step 3: Override the existing data transform in your application ruleset as shown below.
Now your workparty rule is ready. Let’s test it.
Step 4: Create the new workitem in user portal.
- Select VOE in party roles in key here.
- Remember to ‘uncheck’ create new harness in the process tab of the flow rule and add harness as “New”.
- On the new harness, you will see form to enter the party details.
- Remember you made only Customer as required and set VOE.
- Other roles like Agent & Interested are optional and can be added.
From here you can add the workparties manually. Since Interested is repeatable, you can add it multiple times.
Now, uncheck the VOE for workparty and test it.
You won’t see any fields to add in new harness.
Now you may get a question, “Where do we debug, if workparty is added to the work item?“
How to debug workparty manipulation?
- Configure the workparty as shown below and use tracer, when you create a case.
You can see an activity ‘PartyNewSetup’ gets called from CreateWorkPage during case creation.
PartyNewSetup activity is responsible for appending pagegroup property ‘pyWorkParty’ to pyWorkPage.
Note: Activity adds the roles for which required checkbox is selected. You can manually add other properties using ‘AddParty’ flowaction.
2. Check the clipboard to verify the workparty details and appened with the pyWorkPage.
Create a case by providing the details.
After submitting, check the clipboard for the case thread.
You can see pyWorkParty – PageGroup property representing customer with class ‘Data-Party-Person’.
pyPhoneNumber – Remember we set in a data transform rule ‘AddParty’.
pyWorkPhone – This is what we set in UI.
Where do we use this data party?
- In flow rule, you can use send email shape and send the email to any specific party added.
2. In flow rule assignment shape, advanced configuration you can use OOTB notify activity ‘NotifyParty’ to send email to work party.
3. You can browse and check the standard OOTB notify & router activities that use the workparties.
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“.