Case Study - Application Design – Warranty Application
For this case study, decision has been made to have separate implementations for Boat and Auto division. It is assumed that there are not much differences in warranty process in different countries/plants.
Lets assume that in future these warranty processes start differing in some geography and then the user started asking for localization support too how we will extend the design to accommodate these changes.
Then you would add in a specialization for geography, perhaps class specialization but it would depend on the requirements of the specialization. The localization specialization is always handled separately through the Out Of The Box (OOTB) localization feature (Ruleset specialization).
Posted: 6 years ago
Posted: 25 Jul 2016 11:12 EDT
Ravi Balasubramaniam (RaviBala)
James hi hope you're doing fine. I have a scenario where I have a proposal case and several subcases. The life cycle of the proposal case is 3 or more months. Now if the class structure has to change where the proposal case becomes a child case for a parent proposal case what is the best design approach for this scenario keeping in mind the existing proposal case and new parent proposal case / proposal case are going to coexist.
Posted: 6 years ago
Posted: 25 Jul 2016 21:46 EDT
Lee Pederson (pedel)
Global Tech Enablement, Principal Instructor - LSA
Your class structure does not need to change for a certain case type be declared a child case of another case type.
The same case type can also remain declared as top-level case. When you want to discontinue allowing that case type of be listed in the New Work menu, simply update your Application rule to say it cannot be created directly.
The only thing that might change is the possible addition of code to the child case to update a possible parent case.
Your existing proposal case can check for pxCoverInsKey being non-null. If so, then it is being used as a child case.