Creating many Work Class Properties? Here’s the Real Impact on Your Pega System

Creating many Work Class Properties? Here’s the Real Impact on Your Pega System

Feb 12, 2025

Imagine this:

You’re a Pega architect at a financial services firm. Your team built a sleek app to handle loan applications, customer onboarding, and support cases. But after a year, users complain that reports take minutes to load, and database admins are screaming about a table with 200+ columns. You trace the issue back to one innocent decision: defining properties directly in Work-classes.

This isn’t theoretical—it’s a daily reality for teams that overlook Pega’s data modeling best practices. In this blog, we’ll dissect why Data Objects are your secret weapon against database bloat, slow queries, and maintenance nightmares—while keeping your app scalable and performant.



Why Properties in Work-Classes Become a Liability


In many Pega implementations, multiple case types are built on a common Work‑class group. This design choice means that when you expose properties for reporting or integration, they all reside in one underlying database table. Every property you expose becomes a column, and with multiple case types, these columns add up quickly. Here’s what’s happening under the hood:

Shared Database Table:


All your case types that inherit from the same Work‑ class share a single table in the database.
Think of it like a family photo album where every member’s photo is added to the same page—even if only a few photos are relevant for a particular occasion.


BLOB Storage vs. Exposed Columns:

Initially, case data is stored as a Binary Large Object (BLOB) until you expose specific properties to the database. Exposing these properties converts them into columns.
Assume, a banking app has 10 case types (LoanApplication, AccountOpening, FraudCase, etc.), each with 50 properties and out of it 10-15 unique properties are exposed for its respective case types.


Total columns = 10 case types × 15 properties = 150 columns.


Cumulative Impact on Performance:


Each extra column, even if sparsely populated, adds overhead. When queries run, the database engine must scan through many unnecessary columns, causing:


  • Slower Query Performance: Inefficient data retrieval due to the wide table.
  • Increased I/O Load: More data to process means longer response times.
  • Complicated Schema Management: Schema modifications become riskier and more complex


Common Mistakes & Their Consequences – The Pain Points

When developers overload Work‑classes with too many single-value properties, several critical issues emerge. Here are the main mistakes and their consequences:

🔴 Performance Degradation:

  • Issue: A bloated table with hundreds of columns slows down SQL queries and reporting functions.
  • Consequence: Every query has to scan through many irrelevant or null columns, increasing the execution time and server load.

🔴 Scalability Issues:

  • Issue: As your application grows, adding more case types and properties further bloats the table.
  • Consequence: Future schema modifications become complex and risky, hampering your ability to scale seamlessly.

🔴 Maintainability Nightmare:

  • Issue: Managing a wide table with properties from multiple case types is a maintenance headache.
  • Consequence: Simple updates or changes can trigger cascading issues, leading to costly downtime and errors.




The Data Object Revolution: 3 Steps to Fix the Mess


Let’s solve this with a modular, reusable approach.


Step 1️⃣: Encapsulate Reusable Data

Identify data structures used across multiple case types. Create Data objects for these identified structure. Use Pega built in classes like PegaData-Contact, PegaData-Address etc. as directed inheritance classes for this and check the properties in built classes in inheritance classes and only create properties which are not available.


Examples:

  • Customer details (Name, Email, Phone).
  • Addresses (Street, City, Zip).
  • Products (SKU, Price, Category).


Real-World Example:
Global Retail Corp reduced 50+ duplicate “Address” fields across 8 case types into one Org-Data-Address object and that too much of the field were already existing in parent classes.


Step 2️⃣: Reference via Page/PageList


Link Data Objects to Work-classes using Page (single instance) or PageList (List). You can use a Data object as embedded data in work class but there are other ways too like reference, query etc based on need. See Topic:Creating Data relationship on Pega Academy


Example:

A healthcare provider linked Org-Data-Patient to 5 case types, eliminating 30+ redundant fields and exposed columns in database.


Step 3️⃣: Map to Dedicated Tables

The Data objects can be converted into local storages. So where ever needed ensure data objects map to their own database tables.


For Example: TechBank cut query times by 60% after moving Data-Transaction to a dedicated table.



When to Create Properties in Case types in Pega?


Here are key situations where creating properties directly in Work- classes (case types) is better than using Data Objects in Pega, along with real-world examples and reasoning:


Non-Integrated or Non-Reported Data

Properties are never exposed to reports, dashboards, or external systems.


When Data is Strictly Case-Specific:

Properties are only relevant to the lifecycle of a single case type and will never be reused.


For Transient or Temporary Data

Properties are used temporarily during case processing and don’t need persistence or reporting.


There are some properties which can be used by multiple case types but does not falls under one case type or One data objects.
In such scenario we should try to leverage pattern inheritance and create properties in relevant classes.


For Example: There is a property name Reference ID. This is a property which is used by all types of classes like Work- classes, Data- classes, Int- classes etc.
In such scenario create this property at Organization level i.e Org Class.


Similarly, There is a requirement to track, Last Session ID for a case. It can be used across multiple casetypes like Loan Case, Fraud case, Credit case. In such scenario create this property in Implementation level workpool i.e Org-AppName-Work class.



Objections Addressed

There are some common objects and myths regarding creating the data objects in Pega platform and their usage in real projects.


Myth1: “Defining Data Objects slows down development.”


Reality: Initial setup pays off exponentially.

For example:

Time Saved: Upfront effort to identify and create Data Object: 2 hour.

Time Wasted: Debugging 10 duplicate fields: 10+ hours/year.


Myth 2 - This will not work perfectly with App Studio


Objection 1 - If we are creating Data Object then it is not giving us option to create Data types in organization layer or Built in classes. It is only creating Data objects in implementation classes.


Objection 2 - If we are using App Studio, citizen developers does not have knowledge to inheritance.


Objection 3 - If we are using App Studio OOTB properties are not available.


What are the right practices?

Development by citizen developers does not means violating the architecture, design practices like situational layer cake and build practices of Pega Platform.
When Citizen developers are developing any application in Pega, It does not mean that they are designing the entire application all by themselves without any technical guidance.
The purpose of citizen developer implementing an application is to fast forward the process of development in business term and reduce dependency of Technical team. As a best practices they are assisted by Senior system architect and Business Architects.
Moreover they are allowed to build the application but still the overall design and architecture must be done by LSA. So before the application is handed over to Citizen developer the high level solution, situational layer cake, enterprise class structure etc has been decided already and required assets has been initially built and handed over to these developers with guidance.


Lets talk technically

When you are using app studio you are getting option to select the parent class in app studio. It is possible that you will not get required class to select in App Studio in Pega.

For this purpose, You need to go to Dev Studio, Click on Create Data Type + sign and a pop up will appear. Now select existing Data Type and Enter Organization layer class like Org-Data and click submit. This will apply to any

Now this class will be available as Data Type in App Studio and you can select it as Parent class.


Similarly The OOTB properties are not available in App Studio but if you will go to Dev Studio and Open the properties and Mark it as Relevant Records. It will appear in App Studio.



Conclusion

Database bloat isn’t just a technical issue—it’s a business risk. Slow apps frustrate users, and bloated schemas drain IT budgets. By embracing Data Objects, you future-proof your Pega apps, ensuring they scale gracefully and perform relentlessly.


Key Takeaways:

  • Modularity is Crucial:
  • A modular design separating case-specific and reusable data significantly enhances performance and maintainability.
  • Efficiency in Design:
  • The right data modeling strategy not only improves system responsiveness but also streamlines your development and maintenance workflows.
  • Think Ahead:
  • Anticipate future requirements, such as reporting and integrations, when designing your data architecture in Pega.



Your Action Plan:

  1. Audit existing Work-classes for duplicate properties.
  2. Prioritize high-impact Data Objects (start with Customer/Address).
  3. Share this blog with your team—because nobody wants to explain a 200-column table to the CIO.