Implementing case types
By default, Pega Client Lifecycle Management for Financial Services 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 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