As a client moves through onboarding, maintenance, or offboarding journeys with a financial institution, a wide variety of data and documentation is captured for them and their related parties. Data or documentation can be gathered from third-party providers, reused if on file, and still valid or, in many cases, sourced directly from the customer.

The Client outreach case type enables the client to provide required data or documents through a web self-service mechanism accessed from a laptop, tablet, or phone. Data and documentation received from the client can then be used in the ongoing customer journey.

The following tasks enable you to extend the client outreach functionality. For information about this functionality, see the Client outreach.

During the creation of new Client outreach cases, the system displays a list of customers that the case can be assigned. By default, the list contains the main customer of the case (base Pega Foundation for Financial Services implementations) or any party associated with the case with a Contact role category (Pega Client Lifecycle Management and KYC). Customers can change this behavior to send cases to different parties.

1. In the header of Dev Studio, in the search box, search for and select the ClientOutreachRecipientListPrepare_ext data transform.
   Note: This rule is the extension point for the data transform that retrieves the list of contacts for organizations and the actual client for individuals.
2. Save the rule into your implementation layer by clicking Save as.
   For more information, see Copying rule or data instance.
3. Add parties that can be assigned with the Client outreach case.
4. Save your changes.
   Upon selecting a recipient, the system uses the ConsolidationKey property (a combination of customer and recipient identifiers) to determine whether there is already an active case for the current client and the selected recipient and let the user create a new case accordingly. New cases cannot be created if there are in-flight cases for the same consolidation key as one built after recipient selection. The consolidation key can be modified to consider customers only or can be removed altogether to avoid consolidation.
   1. In the header of Dev Studio, in the search box, search for and select the CalculateConsolidatedKey_ext data transform.
      Note: When the ConsolidationKey is empty, the consolidation logic is not used. The Client outreach case are created without checking for an existing customer.
   2. Make your changes to the data transform.
   3. Save your changes.

When an active case is edited, the data captured on the screen (items and instructions) is transferred into the case to reach the customer eventually. If additional data is required, changes can be done to the PropagateEditedData_ext data transform.

1. In the header of Dev Studio, in the search box, search for and select the PropagateEditedData_ext data transform.
   Note: This rule is the extension point for the PropagateEditedData data transform.
2. Save the rule into your implementation layer by clicking Save as.
   For more information, see Copying rule or data instance.
3. Add data to the case.
4. Save your changes.

Client outreach cases can be withdrawn either automatically by the system or manually by the user. In both situations, cases are closed, and the assignments created for customers to fulfill the requests are deleted. Some additional logic (for example, to send a notification to the recipient or to send a message to the front-end system to remove notifications for customer) can be added to the application by extending the two rules ClosePendingClientOutreachCases_ext and WithdrawPost_ext.

1. In the header of Dev Studio, in the search box, search for and select the ClosePendingClientOutreachCases_ext activity.
   Note: This rule is the extension point for the ClosePendingClientOutreachCases activity that is used to automatically withdraw the Client outreach case.
2. Save the rule into your implementation layer by clicking Save as.
   For more information, see Copying rule or data instance.
3. Make changes to the behavior of automatically withdrawn cases.
4. In the header of Dev Studio, in the search box, search and select the WithdrawPost_ext activity.
   Note: This rule is the extension point for the WithdrawPost activity that is used to manually withdraw the Client outreach case using a local action.
5. Save the rule into your implementation layer by clicking Save as.
   For more information, see Copying rule or data instance.
6. Make changes to the behavior of manually withdrawn cases.
7. Save your changes.

The system generates an email notification to the recipient when the case is created and when there are changes made to the case. In addition, the system can send extra notifications when the case reaches, in the Fulfillment stage, a certain goal or deadline Service Level Agreement (SLA).

1. In the header of Dev Studio, search for one of the following correspondence rules.

   Rule Name	Type	Details
   NotifyRecipientCO	Correspondence	Correspondence sent to notify the recipient in the Client outreach case that there is additional data or documentation required.
   NotifyContactCODeadline	Correspondence	The extension for the WithdrawPost activity Correspondence is sent to notify the recipient that the Client outreach case has reached its deadline SLA.
   NotifyOriginatorCOGoal	Correspondence	Correspondence sent to notify the recipient that the Client outreach case has reached its goal SLA.

2. Save the rule into your implementation layer by clicking Save as.
   For more information, see Copying rule or data instance.
3. Make changes to the correspondence rules.
4. Save your changes.

The logic to build the list of recipients for a given case can be modified or extended. In the Pega Client Lifecycle Management and KYC layer, the list is built using the D_ClientOutreachRecipientList data transform, which pulls any associated party from the case with a role category of Contact.

1. In the header of Dev Studio, search for the ClosePendingClientOutreachCases_ext activity in the PegaCLMFS-Work class.
   Note: This rule populates from pyWorkParty(Customer).
2. Save the rule into your implementation layer by clicking Save as.
   For more information, see Copying rule or data instance.
3. Make changes to the recipient list logic, as necessary.
4. Save your changes.

All the extension points for the Client outreach case can be override using a ruleset specialization (saved in the same class, using a different ruleset). However, if customers want to introduce new types of items (the system currently supports only basic data and documents), they need to create their classes to support those types. The classes need to be created either under the same hierarchy as the default ones or in a new class structure. To keep a clear distinction between base product (Pega Foundation for Financial Services and Pega Client Lifecycle Management and KYC) and customer implementation, apply the second approach.

Pega Client Lifecycle Management and KYC provides an example of how these classes can be extended. New classes are created under the PegaCLMFS rulesets to add new types or change the behavior of the existing types. Customers can follow a similar pattern.

• Pega Client Lifecycle Management and KYC Implementation Guide