Pega Platform :- 8.x / Customer Service for Comm's
We are building our application on top of Pega Customer Service for Comms framework . One thing we observed was that Pega has 2 class groups PegaComm-FW-CF-Work (for Comms Case Types ) & PegaComm-FW-CPMCFW-Work (For Customer Service cases ) . For each case type in Comms class group Pega has a wrapper case type created in the "PegaComm-FW-CPMCFW-Work" class group with a direct inheritance to Comm's class .For example consider the “AddNewService” case type . I believe the reason for this is there are lot of customer service artifacts which needs to be leveraged when we open these case within an interaction portal .
Question :- When we create a new application and select some OOTB Case type like “AddNewService” , “ChangeService” etc we see that Pega creates 2 class groups one extending the Comms class group and second extending Customer Service class group .In addition it also creates “AddNewService”,”ChangeService” in the newly created class group for Comms but IT DOESN’T CREATE WRAPPER case types in the newly created class group for Customer Service. This is different than the behavior we have currently within the Comms framework .Also we dont see the wrappers created for other case types like "ActivateDevice" etc .
So what is the best practice for Case Types .We would want to follow what we have in product and create wrapper case types in "Customer Service class group" .Appreciate your responses.
***Edited by Moderator Marissa to update SR Details***
The current behavior in App Wizard is correct and that's what we expect for implementations. If you have selected a case type from Comms class group (PegaComm-FW-CF-Work); it would be created in the Comms class group created in the implementation app that directly inherits from the Comms class group (for eg. Adjust Charge, Upgrade Device etc). Similarly if you have selected a case type from Hz class group (PegaComm-FW-CPMCFW-Work); it would be created in the Hz class group created in the implementation app that directly inherits from the Hz class group (for eg Address change, Update contact comm options etc).
"For each case type in Comms class group Pega has a wrapper case type created in the "PegaComm-FW-CPMCFW-Work" class group with a direct inheritance to Comm's class"
The above statement is not true for all case types in Comms class group.
Historically, certain case types that were inherited from Foundation like Add New Service, Change Service, Adjust Charge had the above pattern since we were using FCM approach to invoke case types but with single application stack approach (with built-on on Fiundation app) this was redundant.