Implementing case types
By default, Pega Client Lifecycle Management and KYC comes with different cases that you can use from your implementation layer. Based on the functionality of the cases, they can be classified as either journeys or supporting cases.
Journeys
Cases that implement end-to-end journeys in a business, that the application manages. Journeys are instantiated as top-level cases and might require other case types to complete their work.
In the base product, journey cases reside under PegaCLMFS-Work-CLM, a class that defines the generic case lifecycle used as a base by most journeys. For example, the Client Lifecycle Management case in the Case types area of Dev Studio and App Studio. The class structure identifies each specialized journey case.
If you select all the case types when you create your application, you should have the following journey cases available under your main work pool (for example, UPFS-MyApp-Work):
Case type | Class |
Onboard new customer | UPFS-MyApp-Work-CLM-OnboardNewCust |
Onboard related party | UPFS-MyApp-Work-CLM-OnboardNewCust |
Onboard new business relationship | UPFS-MyApp-Work-CLM-OnboardNewBusRel |
Offboard existing customer | UPFS-MyApp-Work-CLM-OffboardExistingCust |
Maintain existing customer | UPFS-MyApp-Work-CLM-MaintainExistingCust |
Maintain business relationship | UPFS-MyApp-Work-CLM- MaintainBusRel |
Customer review | UPFS-MyApp-Work-CLM- CustomerReview |
Customer due diligence | UPFS-MyApp-Work-CLM- CustDueDiligence |
Group management | UPFS-MyApp-Work-CLM- GroupManagement |
Each of these journeys implements different variations, which have name journey subtypes. The journeys are implemented as classes and case types. The subtypes are a qualifier (a property) available to the case that can slightly change the behavior of the journey.
For example, all customers can be onboarded using the Onboard new customer journey. However, the onboarding process for an individual will present some differences compared with the process for an entity. The process for the main entity will also be different from, for example, a subsidiary. The journey subtypes manage all the minor variations over the main journey in the system.
Supporting cases
These cases support the process defined by a journey. Most supporting cases are instantiated as subcases of the journey case, while others are created as top-level cases. However, they all need a journey case to exist. The following supporting cases are available out of the box:
Subcases
Case type | Class |
Global KYC | UPFS-MyApp-Work-GlobalKYC |
Local KYC | UPFS-MyApp-Work-KYC |
Legal Work | UPFS-MyApp-Work-Legal |
Credit Work | UPFS-MyApp-Work-Credit |
FATCA | UPFS-MyApp-Work-Tax-FATCA |
CRS | UPFS-MyApp-Work-Tax-CRS |
eScreening | UPFS-MyApp-Work-Screening |
Adverse Media | UPFS-MyApp-Work-Screening-AdverseInformation |
Requirement | UPFS-MyApp-Work-Requirement |
Business sponsor approval | UPFS-MyApp-Work-BusSponsorApproval |
Fulfillment work | UPFS-MyApp-Work-Fulfillment |
Top-level cases
Case type | Class |
Client Outreach | UPFS-MyApp-Work-ClientOutreach |
Fulfill clustered products | UPFS-MyApp-Work-FulfillmentClusteredProducts |
Previous topic Configuring your operators and security model Next topic Creating a new journey type