Basics of the Common Data Model

Pega Common Application consists of the Common Data Model and Business Components. The Common Data Model consists of different entities that can be reused across enterprise apps, accelerates client implementations, and simplifies integrations. The business components layer are reusable across different industries (for example, Event Driven Architecture, Voice AI)

Pega Platform™ includes a Data Model that has been used for many years. It evolves through a hierarchy of classes, beginning with the standard Pega class and subsequently introducing the PegaData classes as the product develops. As the needs of users continuously evolve, additional elements and attributes are required in the Data Model.

Every Lead System Architect (LSA) is responsible for creating a robust and scalable Data Model tailored to their enterprise application. LSAs also create APIs to retrieve or persist data in local or external systems. However, their approach often varies based on the individual LSA's perspective, leading to a lack of standardized methodology and tools in data modeling. This is where the Common Data Model comes into play.

Note: Common Data Model is rebranded as Common Application from version Pega Infinity 24.2

The Common Data Model provides a foundational framework for developing Data Models for enterprise applications. By providing pre-configured entities, the CDM reduces development time and promotes the reuse of data, thereby improving efficiency and consistency across applications.

Structure of the Common Data Model

The Common Data Model is structured with Entity as Case type Objects, Data Objects (including relations and reference data). The Common Data Model is part of the Common Application, which you must obtain from Pega and import into your own Pega Platform instance.

The primary component of the Common Data Model is the entity. An entity serves as a template that defines the structure of an object. In this context, an object represents any element that your enterprise application processes as part of its business requirements. When defining an entity, the CDM specifies the necessary fields that an object must contain and identifies any additional related data items required for the object to complete a business activity. For example, a customer's account is considered to be an entity.

The Common Data Model also facilitates the grouping of logically related data, which enables easy retrieval of the fields needed for an entity. A group of logically related data elements is known as a data object. An entity can incorporate data objects within its definition.

The Common Data Model also provides data pages that use connectors as their source for operations. These data pages connect to the API layer, which acts as a bridge between the Common Data Model and client applications. The API layer facilitates basic Create, Read, Update, Delete (CRUD) operations with data in local storage.

A data portal is included as part of the common application, enabling you to view all available entities and data objects. The data portal also enables you to examine the relationships between these data objects.

Below is a picture that provides an overview of the components of the Common Data Model and how they are arranged. The outer layer in the picture represents the data portal, which enables you to view and manage entities and data objects. Each entity is a template that defines the structure of an object. Objects represents any element that is processed. Case Types define the workflows that incorporate those processes. Instances are retrieved or persisted by default in local data storage, and a data page is used to connect to the API layer, through which a client application can connect to the Common Data Model.