Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

Understanding class layers

Updated on January 14, 2022

To improve the reuse of rules in your application, understand how Pega Platform organizes classes into class layers. Because classes define the applicability, or scope, of a rule instance, knowledge of the different layers of classes and the way that they inherit from each other is important as you develop applications.

Framework classes

Framework classes define a common work-processing foundation that you extend and modify as implementation applications for an organization, division, or organizational unit. Framework classes belong to the framework layer.

For example, an enterprise that makes auto loans has an auto loan framework application that contains all of the assets needed for the basic auto loan process. The enterprise then develops two implementation applications built on the auto loan framework to meet the specific requirements of its two divisions: a commercial business line and a personal line.

Using the New Application wizard, you can build a new implementation application and its implementation classes on an existing framework application. You can reuse some or all of the case types and data types of the framework application. In your new implementation application, you can use the Dev Studio landing pages, explorers, rule forms, and reports to reuse many of the rules and data objects inherited from the built-on framework layer. For example, while developing a process, you can select specifications or processes in a framework ruleset for reuse or customization in the current application.

When you build an implementation application, you can also create a reusable framework application built on the same framework. You can then extend the framework application so that it is usable by other implementations that you might create later. As a best practice, reuse framework rules and create only specialized rules in your implementation applications. For example, use report definitions in the framework classes that run with the corresponding implementation classes.

Implementation classes

Implementation classes define the extension, reuse, and specialization of assets in a framework layer to meet the business requirements of an organization, division, or organizational unit. For example, you can build two division-level implementations – business auto loan and personal auto loan – on an organization's auto loan framework layer.

Implementation classes belong to the implementation layer. Typically, cases that are related to application processes are instances of case type classes that belong only to the implementation layer.

Organization classes

Organization classes contain enterprise-wide data assets and assets that your application reuses for business logic. Data assets include classes and rules for data stored in the system, and classes and rules for accessing data in external systems by using connectors. Business logic assets include standard properties, decision tables, and service-level agreements.

For example, the auto loans enterprise might want to reuse, on an enterprise-wide basis, the property for employee serial numbers. By reusing this property, the various applications across the enterprise that the employees use can consistently rely on the same serial number property representing the same employee.

Organization classes belong to the organizational layer. In most configurations, your implementation and framework layers inherit by pattern inheritance from organization classes.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us