4.1 Data Objects, Property Modes & Page Types

4.1 Data Objects, Property Modes & Page Types

CSA Exam Focus: Understanding the Pega data model is critical for designing scalable, maintainable enterprise applications. Certified Pega System Architects must understand how business data is structured across the class hierarchy, how Value Modes differ from Page Modes, when to use ordered lists versus associative groups, how scalar property types enforce validation, and how to apply System of Record (SOR) versus System of Reference architectural patterns.

---

Pega Data Architecture: Work Classes vs. Data Classes

Pega applications enforce a strict separation of concerns between business transaction processing and the domain data entities that support those transactions. This separation is architected through the class hierarchy:

Work Classes (Work-)

Case types inherit from Work- (or Work-Cover-). Work classes represent dynamic business processes that move through stages, processes, and steps toward a business resolution. Properties defined directly on a work class (such as .pyStatusWork, .pxUrgencyWork, or .LoanAmount) track the state, progress, and transaction-specific attributes of a single case instance.

Data Classes (Data-)

Data types—referred to as Data Objects in App Studio—inherit from Data-. Data classes represent reusable business entities that exist independently of any specific case lifecycle. Examples include MyOrg-Data-Customer, MyOrg-Data-Address, MyOrg-Data-Account, and MyOrg-Data-Vehicle. Data classes encapsulate the fields, validation rules, and integration data pages required to model and interact with enterprise entities. Cases reference instances of these data classes rather than redefining individual customer or account fields inside the case type.

App Studio Fields vs. Dev Studio Properties

When a citizen developer or business architect defines a "Field" in App Studio (for example, adding a customer email field to a view), Pega automatically creates an underlying Property rule (Rule-Obj-Property) in Dev Studio. System architects working in Dev Studio configure advanced property settings, including property modes, data access rules, UI formatting qualifiers, and table validations.

---

Property Modes: Value Modes vs. Page Modes

Every property in Pega has a Property Mode that determines whether it holds raw scalar data or structured class instances, and whether it stores a single item or a collection of items.

Pega categorizes property modes into two primary families:

1. Value Modes: Store scalar, un-typed or primitive data values directly. Value mode properties do not have child properties or inner attributes.
2. Page Modes: Store complex Pega class instances (pages). A page mode property points to a defined class and contains child properties, embedded pages, or lists of pages.

                                +---------------------------------+
                                |       Pega Property Modes       |
                                +----------------+----------------+
                                                 |
                   +-----------------------------+-----------------------------+
                   |                                                           |
                   v                                                           v
             [Value Modes]                                               [Page Modes]
    (Stores scalar/primitive values)                            (Stores class instances / pages)
    - Single Value: .PostalCode = "02142"                       - Page: .Customer.Name = "Acme"
    - Value List:   .PhoneNumbers(1) = "555-0199"               - Page List:  .LineItems(1).SKU = "A12"
    - Value Group:  .PhoneNumbers("Home") = "555-0199"          - Page Group: .Addresses("Bill").City = "BOS"

---

Deep Dive: Value Modes

Value modes store raw data values without an associated class structure:

1. Single Value

Holds a single scalar value. This is the most common property mode for simple case and data attributes.

• Syntax: .CustomerName, .TaxRate, .IsActive
• Examples: .CustomerName = "Jane Doe", .TaxRate = 0.0625, .IsActive = true

2. Value List

An ordered collection of scalar values indexed by positive integers starting at 1 (1-based indexing: 1, 2, 3, ... N).

• Subscript Type: Integer index (1..N).
• Ordering: Strictly ordered. Elements maintain their sequential insertion position.
• Common Use Cases: Chronological search history, ordered priority codes, tags, or simple lists where position matters but child attributes are not required.
• Syntax: .SearchKeywords(1) = "Mortgage", .SearchKeywords(2) = "Refinance"

3. Value Group

An unordered associative array (key-value dictionary) of scalar values keyed by arbitrary text strings (subscripts).

• Subscript Type: String / Text subscript (enclosed in double quotes).
• Ordering: Unordered. Elements are retrieved by their descriptive key name rather than a numerical position.
• Common Use Cases: Categorized contact numbers, localized phone labels, or environment configuration parameters.
• Syntax: .PhoneNumbers("Home") = "555-0100", .PhoneNumbers("Mobile") = "555-0199", .PhoneNumbers("Work") = "555-0144"

---

Deep Dive: Page Modes

Page modes represent structured instances of Pega classes. Every page mode property must explicitly define its Page Class (e.g., MyOrg-Data-Address):

1. Page (Single Page)

A single instance of a specified class. It encapsulates a structured entity containing its own set of child properties.

• Structure: A standalone embedded clipboard page.
• Common Use Cases: Representing a primary customer record, billing address, policy summary, or credit score report on a case.
• Syntax: .Customer.FirstName = "Robert", .BillingAddress.PostalCode = "10001"

2. Page List

An ordered collection of class instances (pages) indexed by positive integers (1..N).

• Subscript Type: Integer index (1..N).
• Ordering: Strictly ordered. Supports sorting, appending, inserting at index, and iterating sequentially.
• Common Use Cases: The most widely utilized aggregate property mode in Pega. Used for repeating business records such as purchase order line items, insurance claim injury lists, bank account transaction histories, and loan co-borrower records.
• Syntax: .LineItems(1).SKU = "PROD-100", .LineItems(1).Quantity = 2, .LineItems(2).SKU = "PROD-205"

3. Page Group

An unordered associative array (collection) of class instances (pages) keyed by arbitrary text subscripts.

• Subscript Type: String / Text subscript (enclosed in double quotes).
• Ordering: Unordered. Elements are addressed directly by their meaningful business key.
• Common Use Cases: Multi-address structures keyed by address purpose ("Billing", "Shipping", "Corporate"), vehicle records keyed by Vehicle Identification Number (VIN), or insurance coverage endorsements keyed by endorsement type ("Collision", "Comprehensive", "Liability").
• Syntax: .Addresses("Billing").City = "Boston", .Addresses("Shipping").City = "Cambridge", .Coverages("Collision").DeductibleAmount = 500

---

Technical Property Types (Scalar Types)

For properties configured in Single Value, Value List, or Value Group modes, Pega requires selecting a technical Property Type. This type governs how the platform formats, parses, and validates the data in memory and during database persistence:

---

Systems of Record: SOR vs. Reference vs. Temporary Data

Architecting enterprise Pega applications requires deciding where data lives, how long it persists, and which system owns the single source of truth.

1. System of Record (SOR)

The System of Record is the authoritative master database, ERP, or CRM system that creates, owns, and permanently persists enterprise entities. Examples include SAP for inventory, Salesforce for sales leads, and core banking mainframes (e.g., FIS, Fiserv) for deposit accounts.

• In some applications, Pega itself acts as the System of Record for case data (stored in pc_work tables) and internal data types (stored in dedicated pr_ relational tables).
• When external systems own the data, Pega must coordinate updates using integration connectors or Savable Data Pages to synchronize changes back to the SOR.

2. System of Reference

Under the System of Reference pattern, Pega does not persist a duplicate copy of the master data within the case work table (pc_work). Instead, Pega queries the authoritative SOR on demand using Data Pages whenever the case needs to display or evaluate the information.

• Operational Advantage: Eliminates data duplication, eliminates stale data risks, and maintains compliance with strict data privacy laws (such as GDPR or CCPA) because customer personally identifiable information (PII) is not serialized into the case BLOB.
• Case Integration: Cases store only the foreign key (e.g., .CustomerID = "C-501"). When a view needs to display the customer's name and credit tier, it references D_Customer[CustomerID: .CustomerID].CustomerName. The data is retrieved on the fly and discarded when the user session or interaction concludes.

3. Temporary Data Objects

Temporary data objects are ephemeral clipboard pages created in memory to facilitate in-flight calculations, user selections, or transient validations. They are never persisted to any database table.

• Examples: A shopping cart checkout tax estimation page, a pre-qualification loan simulator results page, or a dynamic address verification lookup page.
• Once the case advances past the calculation or review step, the temporary page is removed from the clipboard using a Data Transform Remove action to keep memory footprints low.

---

Property Mode Reference Table & Syntax Guide

The following reference matrix outlines the syntax, subscript mechanisms, and architectural applications for each property mode: