
1. Introduction
Pega data modeling defines how data is structured, stored, and accessed within a Pega application. Following proper data modeling standards ensures application scalability, performance, reusability, and maintainability.
This document outlines the latest industry‑aligned Pega data modeling standards recommended for Pega Infinity releases (8.x–24.x).
2. Core Principles of Pega Data Modeling
2.1 Reusability
- Design data structures that can be reused across multiple case types.
- Use Data Types to define reusable data objects.
- Avoid creating duplicate properties or data classes.
2.2 Performance Optimization
- Use Data Pages instead of direct database calls.
- Load data asynchronously where possible.
- Minimize clipboard bloat with correct data scoping.
2.3 Scalability
- Use data structures that support large-scale applications.
- Prefer external databases for large reference datasets.
2.4 Maintainability
- Use meaningful naming conventions.
- Group related properties into data classes.
- Document data objects with descriptions.
3. Data Types (Data Objects)
Data Types represent reusable objects such as Customer, Address, Order, etc.
3.1 Best Practices
- Create Data Types for any object used frequently.
- Use pages and page lists inside case types instead of creating flat properties.
- Follow packaging standards (rulesets, application layers).
3.2 Naming Conventions
- Class names should be noun-based: Org-App-Data-Customer.
- Avoid abbreviations unless commonly understood.
- Use singular names for page properties and plural for lists.
4. Property Design Standards
4.1 Property Types
- Use Text, Integer, Decimal, DateTime, Boolean appropriately.
- Use Picklists for UI dropdown values instead of manual property creation.
- Use Page or Page List for grouped data.
4.2 Naming Conventions
- Use clear, descriptive names: CustomerFirstName, OrderDate.
- Avoid prefixes like px, py, pz (reserved by Pega).
- Boolean property names should begin with Is / Has.
4.3 Documentation
- Add descriptions for every property.
- Document calculations or dependencies.
5. Data Pages (D- Pages)
Data Pages are used for loading, caching, and providing data.
5.1 Data Page Levels
- Thread-level: Data specific to a case.
- Requestor-level: Shared during a user session.
- Node-level: Cached across the entire node (best for static/reference data).
5.2 Loading Types
- Read-only: Most common.
- Editable: Used only when intentional edits are required.
5.3 Best Practices
- Always configure refresh strategy properly.
- Use parameters to avoid creating multiple Data Pages for similar needs.
- Use load management to prevent unnecessary calls.
6. Data Sources & Integration Standards
6.1 External Integrations
- Use REST connectors for modern integrations.
- Prefer JSON over XML when possible for performance.
6.2 Database Access
- Use Report Definitions for read operations.
- Avoid Obj methods; Data Pages should be primary data access layer.
- Use external data tables where applicable.
6.3 Data Mapping Standards
- Use Data Transforms for mapping.
- Do not use Activities unless absolutely necessary.
7. Clipboard and Data Storage Considerations
7.1 Avoiding Clipboard Bloat
- Use optimized data page scoping.
- Do not store unnecessary large lists in the clipboard.
7.2 Persisting Data
- Use case data for work-related information.
- Use Data Type tables for reusable objects.
- Use declarative rules to auto-calculate data when relevant.
8. Class Structure Standards
8.1 Class Layers
- Enterprise layer: Reusable for entire organization.
- Division layer: Reusable for business units.
- Implementation layer: Project-specific rules.
8.2 Inheritance
- Apply pattern inheritance for application structure.
- Use direct inheritance for shared components.
9. Data Validation Standards
- Use Edit Validate rules sparingly.
- Prefer Validation rules and Field-level validations.
- Use Picklists, Data Pages, and Constraints for accuracy.
10. Guardrail & Compliance Guidelines
- Maintain a guardrail score of 90+.
- Avoid custom code where possible.
- Follow Pega-provided patterns for data access.
–TEAM ENIGMA