Enterprise Class Structure in Pega


  • Pega is an enterprise software.
  • Designing enterprise class structure is the basic to begin before creating an application.

In  simple words, we are going to map our class structure with the client organization.

Here you can see five enterprise class structure layers connected via Inheritance.

  1. Organisation Layer
  2. Division Layer
  3. Unit Layer
  4. Framework Layer
  5. Implementation Layer

Org, Div, Unit layer are connected via Pattern inheritance.

Implementation inherits from Framework via Direct Inheritance.

What are the Inheritance types?

Pega supports two Inheritance types.

  1. Pattern Inheritance
  2. Direct Inheritance

Let’s see an example first,

You are in a Pega application using a case – Purchase request case.

Implementation class – Amazon-IN-OnlineSales-Work-PurchaseRequest.

Framework class – Amazon–FW-OnlineSalesFW-Work-PurchaseRequest.

Purchase request case contains a sub-process ‘CustomerSearch’ flow.

When the primary case creation flow advances to sub-process, pega use rule resolution algorithm to find the ‘Customer search’ flow.

1. Pattern Inheritance

Pega uses pattern inheritance to check the flow rule available in the class path.

  • It means, first it checks ‘Amazon-IN-OnlineSales-Work-PurchaseRequest’.
  • If rule is not found, then pega checks ‘Amazon-IN-OnlineSales-Work’ class.
  • If it is not found again, then it checks ‘Amazon-IN-OnlineSales-’, checking process continues till ‘Amazon’.

2. Direct Inheritance

You can specify a direct inheritance class in the class rule form.

Class ‘Amazon-IN-OnlineSales-Work-PurchaseRequest’ can directly inherit from framework class ‘Amazon–FW-OnlineSalesFW-Work-PurchaseRequest’.

You can find the pattern inheritance directly from the application class path, while for direct inheritance you need to check the class rule form – general tab.

You can also specify whether pattern inheritance is applicable or not.

  • If ‘Find by name first’ pattern inheritance is checked, then pega checks for pattern inheritance first.
  • If rule is not found, then the rule resolution algorithm checks the class specified in direct inheritance class field.
  • It goes on till @baseclass. All class inheritance ends in @baseclass.

 Now let us discuss the Enterprise Class Structure.

We will proceed with Amazon organization example.

Amazon extends its organization in 2 divisions: United States and India. Each division has 2 separate departments – Sales and Service.
Amazon wants the development team to create an application for sales & service department in US division.

If the application is successful, then they may want to extend it to other departments and divisions.

Step 1: Map the organization structure:

Organization – Amazon

Division          – US

Unit                – Sales

Step 2: Create a new framework application. – CRMFW.

We discussed about framework application in ‘Framework vs. Implementation’ (http://myknowpega.com/2017/05/13/framework-vs-imp…ion-with-example/)post.

Click on the application menu and create a new application.

We will see more of the application creation in a separate lesson.

Configure the advanced settings.

After creation, open the application. On header, Application menu -> Open Application

Open the Framework application and check the rulesets.

  • CRMFW, CRMFWInt –Framework and its Int ruleset
  • Amazon, AmazonInt – Organization and its Int ruleset

Step 3: Create a new Implementation application for Sales department.

Application menu -> New Application

Build-over application is CRMFW framework

Configure the advanced settings.

If you see below, we don’t use ‘Generate reusable division records‘. So our implementation class structure will be Amazon-USSales-Work

In our scenario, we need to reuse division layer, since we are creating applications for different departments for each division. US – Sales + Service.

So, our class structure will be – Amazon-US-USSales-Work

Open the Implementation application and check the rulesets.

  • USSales, USSalesInt – Implementation and its Int ruleset
  • AmazonUS, AmazonUSInt – Division and its Int ruleset
  • Amazon, AmazonInt – Organization and its Int ruleset

Step 4: Now let us create another Implementation application for US division – service department.

Complete the advanced settings. Make the division as reusable layer. So our Implementation class will be Amazon-US-USService-Work

Open the application and check the built-on application and ruleset list.

  • USService, USServiceInt – Implementation and its Int ruleset
  • AmazonUS, AmazonUSInt – Division and its Int ruleset
  • Amazon, AmazonInt – Organization and its Int ruleset

From step 2, 3 & 4, you have created a framework application and two implementation applications.

After checking the rulesets, what do you infer?

1. First let’s go with framework application

  • Both the implementation application are built over framework. So all the framework application rulesets are visible to both implementation rulesets.
  • It means what are the rules in framework application that can be accessed by implementation application.
  • Organization rulesets are added in the framework application – It means that rules in the organization rulesets can be accessed by any implementation application in that organization.

This is the reason why organization specific Integrations are included in organization layer.

2. Implementation applications

  • Both the implementation applications share the common organization and division rulesets.
  • Since both the implementation Sales & Service are over US division, they share the common division rulesets.

Now, let us look at map the Implementation application with the enterprise class structure.

Each Enterprise layer can contain sub layers. There are three common sub layers:

  1. Data
  2. Int
  3. Work

Organization Layer:

  • This layer is the top most layer.
  • We can include many divisional layer for a particular organization layer.

Ex: Amazon-US, Amazon-IN can be the two divisional layer which inherits from Amazon – Organizational layer.

  • Specify the organization’s specific rules in this layer, so that when a new division comes in, it will inherit from organization and the rules can be re-used.

Ex: Company logo specific UI rules – You can specify the UI rule in organizational layer.

  • Organization layer contains two sub layers – Data, Int.

Follows Pattern Inheritance.

Division Layer:

  • This layer inherits the organizational layer.
  • Each organization can contain multiple divisions and each division can contain multiple departments/units.

Ex: Here, Amazon-US & Amazon-IND are the two divisions.

  • Specify the US division specific rules in Amazon-US- layer, so that the above implementation application can inherit from division layer.

Ex: Amazon-US-USSales-Work & Amazon-US-USService-Work are the two implementations that can inherit the common rules from Amazon-US- path.

  • Division layer contains two sub layers – Data, Int.

Follows Pattern Inheritance.

Unit layer:

  • This layer inherits from division layer.

This is not applicable in our example, since we re-used till the division layer.

You can try the same by re-using unit records.

Then your implementation class will be like,


You can specify the Unit specific rules in Amazon-US-Sales- class so that implementation can re-use those rules in the inheritance path.

Framework Layer:

  • This is the framework part of the application which can be extended to any application.

You can create as many applications implementing on different divisions or unit, using built-on application as framework application.


  • If you see the framework class, you can understand like this inherits from only the generic organization layer (Amazon-).
  • You can bring all the common rules, common to implementation application to this framework layer.

Now you may get a question, “Why cant I reuse the organization layer as a framework layer?

You can see the answer in this picture.

Yes, framework layer can include three sub layers – Data, Int, Work.

  • All the process specific common rules can brought under work sub layer.


  • Create the common rules which can be reused across different applications.

Ex: Customer data type, Customer search UI can be included in framework application. Since this may not change for different departments or divisions.

Implementation layer:

  • This layer contains all the implementation specific rules.
  • Implementation layer inherits from framework layer.

Type of inheritance is direct inheritance. You can specify the Class in the class rule form.

So Implementation class can use the rules specified in the framework class by inheritance path.

Bring all the rules which are specific to the particular implementation to this layer.

Implementation class cannot be inherited by other class layers.

Try creating various applications and check the ruleset list and class structure created for the same.

Hope you get the basics about Enterprise class structure

Please read it more than once to understand clearly 🙂

Feel free to drop comments below 🙂

74 thoughts on “Enterprise Class Structure in Pega

  1. Good read. This is most trickiest design aspect in which you have to for see how the application would be scalable for future requirements. I believe good ECS can be built only if you consider all future requirements and the key for this would be to extract such info from architects or business. It would be good idea to have a master list of questions which we need to ask to design ECS. Eg Which all countries would this application be used, how different are the business processes in each country..etc

    1. Exactly. I hope I added only the basic in the post. ECS is not a simple thing. We have to sit and analyze.

      ECS – the blueprint of our application

    1. As well as could you please share your knowledge on Declare Index rule, Flow actions, Report definition And more on all methods of Activities..

      Thank you So much Prem for your patience.

    1. BPM – Business Process Management
      BRE – Business Rule Engine

      If all the business can be handled within the rule engine, then we call that application as BRE application.
      BRE application focus on reducing the IT involvement.generally automating rules like Declaratives support BRE.
      Imagine a Pega application used only at the back end to process the service requests from other applications. These are pure BRE applications.

      BPM applications are process oriented.
      Most of the Pega applications are BPM.

      Hope you are clear now

  2. You could even add a section on nested units and explain how it can simplify complex organization hierarchies which usually cannot be fit in 3 layers.

  3. Nice Explanation Prem!!! Keep going with all topics and use cases and realtime scenario’s. Appreciate your effort in detail explanation.

  4. Hey!

    One question. In the beginning, you described how to create framework and implementation.
    And currently, implementation ruleset stack looks like (including framework’s rulesets):
    USSales 01.01.01:
    USSales: 01-01
    USSalesInt: 01-01
    Amazon: 01-01
    AmazonInt: 01-01
    CRMFW 01.01.01:
    CRMFW: 01-01
    CRMFWInt: 01-01
    Amazon: 01-01
    AmazonInt: 01-01

    The problem here is that organization rulesets (Amazon and AmazonInt) include in both layers. And on my understanding, it should be removed from implementation layer.
    Am I right?

    1. Exactly Basil. I got this same doubt years before 🙂 You can remove the Org & OrgInt rulesets from Implementation layer.

      The reason for this behaviour:
      In the Create new application wizard, we can create either Implementation application alone or both Framework & implementation application.
      So when you create an Implementation application alone, Pega adds the Org rulesets in Implementation application rulesets.
      The coding is done like that. COOL 🙂 So it always gets added in both the layers.

      You can remove those rulesets.

    2. The reason for being org rule sets in imp layer is,if at all if you want to add some more features to org level as part of the application ,which may be used some other applications of same organasation. If it is not in the stack,pega wont show that ruleset if you want to create any rules at org level.

  5. Thank you prem..!
    This is the best pega knowledge source which i came across.
    I really appreciate your efforts for sharing the knowledge.
    can you please provide a blog on Decisions too.it will be great if you can give one scenario on how to call decision tree/table using expressions, I am really confused here.

    1. Thank you so much, Abdul. Your words are really encouraging me a lot. 😀
      Okay Abdul, noted. Will post it soon 🙂
      Please subscribe and stay tuned for more posts.

    1. Thank you so much, Fariyal. Happy that you like it!
      Please subscribe and stay tuned for more posts. 😀

  6. Hi Bro , I have just saw your website how u guys were designed , it was very good & easy way to learn PEGA . As im a mechanical engineer completed on 2015batch , now i wish to go into IT sector . So, i choosed PEGA …..Can you help me that first were i want to start my reading in Pega ??

    1. First of all, sorry for late reply. Got busy with my office works. Good that you chose Pega. Unless, you get into any Pega partner organization like CTS, TCS, etc., you cannot access PDN site. So it is better that you try some training institutes to get certified. For reference, you can visit my site 🙂

  7. Hi Prem,

    Fantastic Work..!! Really appreciate your work.

    I would like to know more about Activities and different methods used in it along with detailed explanation( for ex Looping in activities , Integrations in activities, RDB concepts in activities)

    I hope you will consider my request.


    1. Thank you so much for your encouraging words, Prince.
      Yeah, Prince, I’ve noted down the things. Will post them soon. 🙂
      Stay tuned for new posts. 🙂

  8. Hi Prem,

    Really the way of explanation is very good thanks for sharing this things with us ….i have a query in inheritance direct inheritance is a mandatory , can you please explain me why it is mandatory as of my knowledge for rule resolution it is mandatory but explain in detail please .

    thank you .

    1. Hi Soumya,
      Yes. we use direct inheritance for rule – resolution.

      For example you have a class AAA-XXY-Work. You need to use some properties, or say like you need to reuse some functionalities in another class structure – BBB-ZZZ-Work

      As per rule resolution checks the rule in pattern & direct inheritance.
      So in order to use the functionality, we can configure AAA-XXY-Work to direct inherit from BBB-ZZZ-work.

      So we basically inherits the functionality here and reuse it 🙂

      Hope you are clear now

    2. its mandatory because internally pega needs to call lot of other rules which requires some class in Direct inheritance path .. as you ware we will be having three four top parent classes,@baseclass,work-,data-,int-..To identify top parent class
      direct inheritance is required.

  9. Hi Prem,

    I have a doubt here the framework layer is built upon organisation layer right but in diagram it is inherited from pega base product there i find little confusion in between them, could you elaborate the thing!!

    1. Hi rohan, In that diagram, just look at the connectors again :).
      Organization layer usually inherit from pega product class.

      Similarly framework layer directly inherit from pega base product class !!

  10. and also give a detailed explanation of activities and report definitions and tracer. it would be very helpfull especially for freshers .

    1. Integration rulesets are generally used to hold all the integration specific rules. It is a best practice to place integration rules under Int rulesets

  11. Nice excellent information. Great, keep posting all valuable information so that it will be easy for beginners to get an idea.

  12. Nice explanation bro.Very helpful for freshers to learn.Keep it up.

    If you are taking online or offline classes please share the details bro so that people can join .

    1. Thank you so much Naveen. 🙂
      Feeling elated on reading your comments 😀

      Right now I’m not taking any classes neither online nor offline. But I’m planning to have video tutorials after 6 months or so.
      Stay tuned, Naveen. 🙂

  13. Hi Prem,

    You have mentioned that ui specific rules such as company logo can be present in the organization layer.
    But we can see that organization layer is having only two sublayers of data and int so where will we build ui rules if we r not having work

    Please help me as I tried to reach yu previously as well but haven’t received any reply.

    Thanks for yur help.

    1. Hi Sheweta, I understand your question. Let me explain using company logo. Company logo is not specific to work layer. So you can place the rule directly under ‘-‘. Likewise you can place some generic organizational rules under org layer. Hope you are clear now!

  14. Hi Prem

    You did a great job.

    Can you post brief details about the Casetype, stages and steps with any best real time example

    Thanks in Advance

  15. Hi Prem,

    All topics are covered very nicely!!. its really awesome!!

    Could you explain about Case management and Pega Methodologies for ex Scrum
    I am looking for your update

    Thanks in advance

    1. Hello Siva,

      Thank you so much for your appreciation.
      Yeah, I’ll post about those topics soon. Since I was little busy with my work, I couldn’t post any new topic. I’ll try to post soon. Stay tuned.

      Premkumar G

Leave a Reply

Your email address will not be published. Required fields are marked *