Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Configuring client outreach

Updated on May 24, 2021

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.

Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide Pega Client Lifecycle Management for Financial Services Implementation Guide

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.

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. 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.

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 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.

Extending case withdrawal

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.

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).

Change the following rules to modify the content of all email notifications.
  1. In the header of Dev Studio, search for one of the following correspondence rules.
    Rule NameTypeDetails
    NotifyRecipientCOCorrespondenceCorrespondence sent to notify the recipient in the Client outreach case that there is additional data or documentation required.
    NotifyContactCODeadlineCorrespondence

    The extension for the WithdrawPost activity

    Correspondence is sent to notify the recipient that the Client outreach case has reached its deadline SLA.

    NotifyOriginatorCOGoalCorrespondenceCorrespondence 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.

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 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.

To change this logic, modify the data page or the data transform that feeds its content.
  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.

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 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.

ClassParent ClassUsage
PegaCLMFS-Data-ClientOutreachPegaFS-Data-ClientOutreachWrapper data class for client outreach
PegaCLMFS-Data-ClientOutreach-ItemPegaFS-Data-ClientOutreach-ItemWrapper class for different items
PegaCLMFS-Data-ClientOutreach-Item-DocumentPegaFS-Data-ClientOutreach-Item-DocumentWrapper class for all document related items
PegaCLMFS-Data-ClientOutreach-Item-Document-BasicPegaFS-Data-ClientOutreach-Item-Document-BasicUsed for holding all basic document items

Tags

Pega Client Lifecycle Management for Financial Services 8.7

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Visit the Support Center

Did you find this content helpful?

Yes
No

Want to help us improve this content?
Suggest an edit

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us