Rethinking the Classgroup

Classgroups have historically provide three benefits. First, they allow multiple classes to share the same table. Second, the group the classes in the class explorer.
Third, they provide a common base for finding the application's processes.

This first purposes is specious. Even without the classgroup, classes will share the table of the pattern ancestor. And following classical database design, you might as well assign classes to particular tables.

The second purpose is helpful: grouping is good. But why group only at the work level? As we regularly group at the work level, we end up missing all of the auxillary classes and then needing to hunt through the explorer for them.

So why not set the "ClassGroup" to be MyCo-FW-App? This would cover MyCo-FW-App-Work-, but MyCo-FW-App-Int-, MyCo-FW-App-Data-, MyCo-FW-App-Rule-, etc.

So let's look at this third purpose. If we want to automatically list all of the processes -- of marginal benefit -- we can still do so if the ClassGroup is a higher level.

I am trying this with my new App. Part of the complication is that the application accelerator has already created MyCo-FW-App-, which Pega asserts is the common ancestor for all of the classes underneath. Since it's abstract, it can't be a classgroup. And since it is thought to be the common ancestor, it can't be deleted.


**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.


Keep up to date on this post and subscribe to comments

October 5, 2011 - 12:38pm

Hey Jon,

I understand and agree with the "marginal value" in the three advantages that you suggested.

But I do not understand how changing the level of the class group to be higher to include all classes beneath it and put all records into 1 table be of any more advantage? Rather, would it not be detrimental to add all records to one table? Too many records/non-normalized? ( I hope I understood your question right)


May 20, 2010 - 3:35pm

It's been almost a month since I asked this, any thoughts?

July 23, 2012 - 11:04am

Just trying to understand: The locking and Keys are defined at the class group level for all the classes belonging to that class group. In your case do you want the same keys/lock for all the Int, Data, Work classes if the class group is at Higher layer.

June 24, 2010 - 11:31am

Not trying to be naysayer but I tried doing it on my personal edition when I actually Started with pega. I tried to change the Abstract to concrete in class definition and but later on it gave me complication while creating workobjects. Since I started working on pega that time, I cld not debug or understand the errors.

April 29, 2010 - 9:54am

Now that everyone is back from PegaWorld, does anyone have any thoughts on this?


December 9, 2012 - 12:04am


I dont understand the the value it would add in terms of extendability, resuability and flexibility.

As per your sugestion, putting all the records such as Data, work, etc in a one table going to increase the complexity and it s going to be non-nomralized data would be in the DB.




August 14, 2013 - 2:31pm

Just responding to this -- lost track of this thread a few years ago.

  • I never suggested using the same classgroup for putting everything in one table. Obviously you should use different tables for different purposes.
  • Classes in a classgroup share locking and keys. I neglected to mention that. But these are almost always standard pyID.
  • The AccessGroup points to a list of Workpools.
  • Your chosen workpool is used as the top-level for the application and class explorers. And this is what is a pain -- since you might want to review your data classes under that -- but, per definition, they are not under a ClassGroup.


January 6, 2014 - 1:27pm

This mostly becomes a moot point in v7, as the Class Explorer has been retired.

July 15, 2014 - 11:44am
  • Classes in a classgroup share locking and keys. I neglected to mention that. But these are almost always standard pyID.

Not really, for when a class belongs to a class group the keys and lock features on that class is completely ignored and the keys and lock on the class group will be taken, and on the classgroup it could be pyID or anything else for that matter.


And also i remember reading somwhere that a class group stores all the work classes instances in a same table with same Keys and same lockstrings so that it will be very flexible to change the class of an instance to another class of the same class group. or something like that :p