@Mayurk33

Thank you for reaching out with your question about class group design—it’s a great topic and definitely worth exploring, especially as best practices continue to evolve.

I’ve shared your inquiry with our Enterprise Technical Solutions Director, who will reply shortly with his insights.

Thanks again for the inquiry—we’ll follow up soon!

@Mayurk33

In general, I like keeping my class groups separate, however there are some consequences as suggested in the portal, for example, reporting on descendent classes do not pick up data from a separate class group (living in a separate table).  In the past, I have also seen issues with parent child relationship display on OOTB UI when the children were in different class groups.  If you are looking to use different class groups for parent/child (cover/covered), I would double check that you can still see the child cases and child case assignments when looking at the case summary.  

Separate class groups is good from the perspective of keeping your data separate across case types. It allows you to create table indexes specific for optimizing queries for that data and we minimize creating a lot of columns that will never be populated.  It also reduces the number of records, thereby reducing the cost of querying.  

The most important thing is that you want to get this done before you go-live.  Once you deploy to prod cases sharing a class group, splitting that up can get really messy.