As a client moves through onboarding, maintenance, or offboarding journeys with a financial institution, a wide variety 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 Community article.

Extending client outreach case creation

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

1. In Dev Studio search for the ClientOutreachRecipientListPrepare_ext data transform.

   Note: This is the extension point for the ClientOutreachRecipientListPrepare data transform which retrieves the list of contacts for organizations and the actual client for individuals.

2. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

3. Add parties that can be assigned to the Client outreach case.

4. Save your changes.

5. Upon selection of 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. If there are in-flight cases for the same consolidation key than one built after recipient selection, new cases cannot be created. The consolidation key can be modified to consider customers only or can be removed all together to avoid consolidation.

   1. In Dev Studio search for the CalculateConsolidatedKey _ext data transform.

      Note: When the ConsolidationKey is be empty the consolidation logic is not used (the Client outreach case will be created without checking for an existing for customer).

   2. Make your changes to the data transform.

   3. Save your changes.

Extending active case data management

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

1. In Dev Studio search for the PropagateEditedData_ext data transform.

   Note: This is the extension point for the PropagateEditedData data transform.

2. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

3. Add data to the case.

4. Save your changes.

Extending case withdrawal

Client outreach cases can be withdrawn either automatically by the system or manually by the user. In both situations, cases are simply closed, and the assignments created for customers to fulfill the requests are deleted. Some additional logic (for example, to send 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 listed below.

1. In Dev Studio search for the ClosePendingClientOutreachCases_ext activity.

   Note: This is the extension point for the ClosePendingClientOutreachCases activity used to automatically withdraw the Client outreach case.

2. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

3. Make changes to the behavior of automatically withdrawn cases.

4. In Dev Studio search for the WithdrawPost_ext activity.

   Note: This is the extension point for the WithdrawPost activity used to manually withdraw the Client outreach case using a local action.

5. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

6. Make changes to the behavior of manually withdrawn cases.

7. Save your changes.

Configuring notifications

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). The content of all these notifications can be modified by changing the rules listed below.

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

   Rule Name	Type	Details
   NotifyRecipientCO	Correspondence	Correspondence sent to notify 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 recipient that the Client outreach case has reached its deadline SLA.
   NotifyOriginatorCOGoal	Correspondence	Correspondence sent to notify recipient that the Client outreach case has reached its goal SLA.

2. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

3. Make changes to the correspondence rules.

4. Save your changes.

Extending the list of recipients

The logic to build the list of recipients for a given case can be modified or extended. In the Pega Client Lifecycle Management for Financial Services 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. To change this logic, modify the data page or the data transform that feeds its content.

1. In Dev Studio search for the ClosePendingClientOutreachCases_ext activity in the PegaCLMFS-Work class.

   Note: This Populates from pyWorkParty(Customer).

2. Save the rule into your implementation layer. For additional information about locked and unlocked rulesets, see Copying a rule or data instance.

3. Make changes to the recipient list logic, as necessary.

4. Save your changes.

Extending the class structure

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 would need to create their own classes to support those types. These 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 for Financial Services) and customer implementation, the second approach is recommended.

Pega Client Lifecycle Management for Financial Services provides an example of how these classes can be extended. New classes have been created (all under PegaCLMFS rulesets), to add new types, or change the behavior of the existing types. Customers can follow a similar pattern.