Configuring client outreach
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.
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.
- In the header of Dev Studio, in the search box, search for and select the
ClientOutreachRecipientListPrepare_ext data
transform.
- Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Add parties that can be assigned with the Client outreach case.
- 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.
- In the header of Dev Studio, in the search box, search for and select the
CalculateConsolidatedKey_ext data
transform.
- Make your changes to the data transform.
- Save your changes.
- In the header of Dev Studio, in the search box, search for and select the
CalculateConsolidatedKey_ext data
transform.
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.
- In the header of Dev Studio, in the search box, search for and select the
PropagateEditedData_ext data transform.
- Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Add data to the case.
- 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.
- In the header of Dev Studio, in the search box, search for and select the
ClosePendingClientOutreachCases_ext activity.
- Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Make changes to the behavior of automatically withdrawn cases.
- In the header of Dev Studio, in the
search box, search and select the WithdrawPost_ext
activity.
- Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Make changes to the behavior of manually withdrawn cases.
- 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.- 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. - Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Make changes to the correspondence rules.
- 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.- In the header of Dev Studio, search for the ClosePendingClientOutreachCases_ext
activity in the PegaCLMFS-Work class.
- Save the rule into your implementation layer by clicking Save
as.For more information, see Copying rule or data instance.
- Make changes to the recipient list logic, as necessary.
- 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.
Class | Parent Class | Usage |
PegaCLMFS-Data-ClientOutreach | PegaFS-Data-ClientOutreach | Wrapper data class for client outreach |
PegaCLMFS-Data-ClientOutreach-Item | PegaFS-Data-ClientOutreach-Item | Wrapper class for different items |
PegaCLMFS-Data-ClientOutreach-Item-Document | PegaFS-Data-ClientOutreach-Item-Document | Wrapper class for all document related items |
PegaCLMFS-Data-ClientOutreach-Item-Document-Basic | PegaFS-Data-ClientOutreach-Item-Document-Basic | Used for holding all basic document items |
Previous topic General settings Next topic Modifying the welcome pack