This is not a scenario for Circumstancing/Specialization, so I would suggest not to go with this approach if getting different prefix is the only requirement here.
You can set the pyWorkIDPrefix property on work page based on your requirement (dropdown/decision table ...). There should not be any harm in generating different prefixes for same Case. Only thing you will have to make sure is that Work ID Prefix column in empty in Application's Case And Data tab for this case, otherwise that value takes precedence over pyWorkIDPrefix.
Let us know if you have any other questions.
Posted: 6 years ago
Posted: 21 Jun 2016 22:40 EDT
Abhijith Kolanakuduru (Abhijith_CLSA_v62)
Pega Certified Lead System Architect
As PEDEL mentioned, You can circumstance the Case Type rule for a given work type class if all you want is a different way to orchestrate flows. This is called "Case Type Specialization". Remember that you should choose this option only when you have a case type with different variations but not 2 different case types.
Request Case type: PC Service Request & Laptop service Request - These are 2 requests but a little variation in their process. You should use "Case Type Specialization". In this case it's 1 class :)
Order Case type & Activiation Case type are 2 different case types altogether, so you shouldn't use "Case Type Specialization". In this case, it's 2 classes.
Posted: 6 years ago
Posted: 22 Jun 2016 10:43 EDT
Vigneshwaran Aravindhan (VigneshAravind)
Senior Technology Architect
Assuming we have two cases VV-XX-101 & YY-ZZ-101 in a P7 application.
Do you expect both of them belong to a single work class OR two different work classes ?
Different classes >>> Leverage "Case Type Specialization" using one of the properties in your work class. Also case type specialization is based on only one property (in our case pyWorkIDPrefix) once used it cannot be leveraged again for any other requirements. Specialized cases represent a small variance in the functionality however you had mentioned that the functionality is identical. So leveraging "Case Type Specialization" here is not a good design but somehow achieving the requirement.
Same class >>> Say A-B-Work-C but different prefixes based on user selection. I bet its a bad way to segregate cases even if you somehow manage to implement it. Does not confirm with any existing design patterns I am aware of; might lead to issues later in reporting and upgrades/updates. Every case that belongs to a work class should have the same prefix. This is decided at RULE-APPLICATION > 'Cases & data' Tab > Case types > Work ID prefix if you are in P7.