What is WorkParty? How to configure and use WorkParty in PEGA?

On a quick note, we have two messages for you all

> OneStopPEGA family has now grown from 3 to 120+ 😎

> On the eve of Diwali, we wish you all a happy and prosperous Diwali 😊✨😊

Before We Begin

Let us understand what a WorkParty in PEGA is and then deep-dive into its technical discussion.

Consider Claims Application with below case life cycle

• Customer calls a call center agent to report a problem.
• Agent receives the call, records the customer information and submits the request.
• It is then routed to the appropriate Manager to take action. Manager will then work on the closure of the request.

Actors involved in our case would be “Customer“, “Agent” and “Manager“.

How does the system keep track of which customer called to report problem, which agent submitted the customer request and which manager worked on the closure?. All our questions can be answered in one word – “WorkParty“.

Yes, WorkParty helps us identify actors for each case and record their information in case which are mainly used for Routing/Notification/Reporting.

Classification of Party in PEGA

Party roles are not limited to Operators, it can also be a person/ company/ Non-Profit organization and so on. PEGA has OOTB option to classify party into different types as discussed below:

Data-Party-Operator

Let’s consider the same claims application. Manager who processes the request is an individual operator in PEGA and his/her details need to be recorded in the case. This can be achieved by adding the manager as a work party of class “Data-Party-Operator“.

Data-Party-Person

Let’s consider an application for online shopping. For each purchase request submitted, a case needs to be created in PEGA and details of the customer who initiated the request needs to be recorded in the case. Since customer is not an operator in PEGA, customer details can be recorded as a work party of class “Data-Party-Person“.

Data-Party-Com

Let’s consider a dispute application. When a dispute is raised against an organization, information regarding the organization needs to be recorded in the case. This can be achieved by adding the organization as work party of class “Data-Party-Com“.

Data-Party-Org

Let’s consider an application built for CybageAsha [Non-profit organisation in India]. Each initiative that is taken by CybageAsha needs to be created as a case in PEGA and the details of this non-profit organization needs to be recorded in the created cases. This can be achieved by adding CybageAsha as a work party of class “Data-Party-Org“.

Data-Party-Gov

Let’s consider an application built for Tax Department. Each question raised by individuals regarding local taxes needs to be created as a case in PEGA and details of the Tax Department needs to be recorded in the created case. This can be achieved by adding Tax Department as work party of class “Data-Party-Gov“.

How to identify list of Parties for our case?

It is not difficult to identify the list of parties for a case. First, we should be clear on the case life cycle and the different actors who can participate in the case life cycle. Once identified, we should classify the parties based on the role and proceed with configuring Work parties.

How to configure WorkParties in PEGA [Design Time]?

WorkParty is a rule type in PEGA. It can be accessed from,

Records explorer-> Process-> Work Parties

Create and configure Work Party rule with all identified actors details.

• Party label-> A unique label for each identified party. This label will be shown in UI when VOE/Display on Creation is enabled for a party to collect information.
• Role-> A unique identifier for each party. This field represents the actual role of the party. Role mentioned here will be displayed along with Work party details in participants section of the case.
• Party class-> Mention the party class based on the identified role. This will be used for rule resolution while populating the party details in the case. We can also create our new party class by extending Data-Party class.
• Party prompt-> A short description of the party.
• Data Transform-> Mention Data transform to populate the work party details. We can either reuse PEGA provided Data Transforms or introduce new Data Transform for the mapping.
• VOE/Display on Creation-> Visible on Entry. This can be selected, if party details need to be collected and mapped before initiating the case. When selected, a section “pyNewWorkPartyDetail” will be visible in the new harness to collect the party details.
• Required-> When selected, the party details in the case will be marked as mandatory in NEW harness and case initiation will not happen without its existence. When Required checkbox is selected, “VOE” will be disabled.

How to collect information & add Work Party in PEGA [Run Time]?

Information required to populate work parties in the case can be collected and mapped using any of the below suggested ways based on the need.

• Enable either VOE or Required option for a party, so that PEGA uses section “pyNewWorkPartyDetail” in NEW harness to collect and map the required information.
• If the work party details are dynamic and is known only during case processing, we can configure an utility/flow to invoke OOTB API “addWorkObjectParty“.
• If the work party needs to be added on-the-fly , then OOTB flow action “AddParty” can be used to add party details.

Let’s look into a real time example of using Work Party to understand it better.

Business Scenario

Let us implement work parties for the same claims application which was discussed at the beginning of this post.

The identified parties are “Customer“, “Agent” and “Manager“.

• Customer-> Customer is not an operator in PEGA and hence can be added as party of class “Data-Party-Person“. VOE can be enabled for Customer party and agent can collect customer information in NEW harness before creating the case.
• Agent-> Agent is an operator in PEGA and can be added as party of class “Data-Party-Operator“. Agent who is currently logged-in [Current Operator] and submits the request should be added as Agent party of that case.
• Manager-> Manager is an operator in PEGA and can be added as party of class “Data-Party-Operator“. Manager information should be populated with a custom logic based on business need.

Work party configuration for the above scenario would be,

Customer

Agent will receive call from customer and VOE will prompt Agent to fill in Customer details before submitting the request. This screen can be customized to collect additional information based on the need. System executes data transform “NewParty” mentioned in the Work Party rule to map the party fields.

Agent

When Agent submits the request, the current operator information needs to be recorded as “Agent” party in work item. This can be achieved by invoking OOTB API “addWorkObjectParty” to add work party. System executes data transform “CurrentOperator” mentioned in the Work Party rule to map the party fields.

Manager

Manager information should be recorded in system based on the business logic. Since we don’t have any logic to populate manager field, it is now hard-coded to one single manager. System executes data transform “pyOtherOperator” mentioned in the Work Party rule to map the party fields.

Below is the sample case created with all the mentioned configurations. Participants section of case displays the party list and its information.

Where do we use this WorkParty information in PEGA?

Recorded work party information can be used for any of the below purposes.

• Assignment routing can happen based on the configured Work Party detail. In our scenario, routing to manager for taking the appropriate action can be achieved by routing to Manager work party [PEGA recommends routing with work party, the reason being is when an assignment with default routing option “ToCurrentOperator” is performed from an Agent, routing fails].

• Notification can be sent out from PEGA using Work Party detail. In our scenario, manager can be notified on the assignment creation by using the custom notification [NotifyParty] in assignment properties.

• Communication emails can be sent out from case using WorkParty details. In our scenario, case acknowledgement email can be sent to customer using Party details in Send email smart shape.

• Parties can be notified as part of Goal, deadline and passed deadline actions from Service Level Agreement rule. In our scenario, when goal and deadline time is reached for a request, reminder can be sent to manager by referring party.

• OOTB Declare index rule “PartyURI” helps us expose all details added as part of Work party. This index rule can be directly used for reporting purpose. In our scenario, reporting requirement on the list of cases created by a specific agent can be implemented using below configuration,

This concludes our discussion on Work parties. Happy learning 😎

Stay tuned for more articles on Case Management !!