Primary entities
In a Data Model, entities describe an object, such as a person or an item, by grouping a set of related fields. Products, accounts, and transactions are examples of potential entities in a Data Model. The Pega Common Data Model is a unified foundation for building industry-specific solutions. By grouping related fields into entities that represent business objects (for example, accounts, contacts, products, or transactions), the Common Data Model supports you in developing consistent, cross-industry solutions.
An entity relationship diagram (ERD) shows the entities, including Embedded Data within them, and the relationships between them. To view the ERD for the Common Data Model, see Common Data Model Entity Relationship Diagram.
Entity descriptions
The following table describes each of the primary entities:
| Entity | Description |
|---|---|
|
Account |
Represents a buying or selling relationship such as a customer, competitor, partner, or provider to the client organization. The account holds the aggregate value to the client organization. This entity includes a tab for each type of account: Business, Consumer, and Household. |
|
Agent Performance |
The measurement and evaluation of a human agent's (a CSR) effectiveness, efficiency, and quality of service in handling customer interactions or tasks. |
|
Appointment |
Appointment information describes the when, where, and with whom the meeting will include. |
|
Asset |
Describes the products, services, devices, or anything else that is included or associated with the contract that is stored in the service account. This includes descriptions of the purchased product, physical items (such as devices, cards, and cars) either purchased or covered, benefits, coverages, and discounts. |
|
Authorization |
An authorization request typically contains the items that are requested for reimbursement. Sometimes it is referred to as a prior authorization or pre-approval. In healthcare, typically the doctor or provider submits an authorization request to the insurer for coverage because the items have been deemed medically necessary for a patient. |
|
Claim |
Primarily intended for the healthcare and insurance industries. A claim contains the items (services, tests, medications, accident, and damages) that have been submitted to the insurance company for payment. In healthcare, typically the doctor or provider submits the claim. In insurance, the insured parties submit claims for items that have been damaged. |
|
Contact |
Individuals who play a role in an account, service account, or asset entities. |
|
Investment Performance |
Information concerning an investment portfolio's performance for a pre-defined set of timeframes and portfolio segments. |
|
Location |
Represents the places of business operation that are involved in transactions, claims, or other actions. For example, in healthcare, a physician (contact) offers specialties at a location for a hospital chain (account). |
|
Product |
Contains (Common-LDM-Entity-Product class) information about the products being sold and typically is sourced from the client's product catalog. |
|
Product Family |
Represents a logical grouping of product definitions based on their intrinsic functional purpose, shared attributes, and lifecycle behavior. It provides a consistent abstraction layer for governing product characteristics independent of product commercialization. |
|
Product Offer |
Details the specific features, benefits, and pricing of a product or service that a company is currently presenting to potential customers. It outlines what the customer can expect to receive when they purchase the item, including any special conditions or limited-time deals that are associated with the offer. |
|
Service Account |
Represents contracts between the customer (account entity) and a supplier of products and services. In financial services, the contracts are what consumers refer to as their account, such as their credit, or checking or savings accounts. Other industries use terms such as policy, plan, or group plan. |
|
Statement |
Text information (Common-LDM-Entity-Statement) that is found on a customer's statement including details and aggregate values, which are typically sourced from a customer's system of record instead of being aggregated within Pega as part of displaying the data. |
|
Transaction |
Represents any exchange or transfer of goods, services, or funds. |
|
Transaction Module |
Describes a transfer of money between parties. The transaction module includes the debit and credit parties and all intermediary agents who are involved in completing the transaction. |
To represent terminology found in each industry, the Common Data Model applies dynamic labels to the data entity class. The following table shows the data entity classes and labels for each industry:
|
Entity |
Financial Services |
Insurance |
Healthcare |
Communications |
Government |
|
Account |
Customer |
Customer |
Customer |
Customer |
Customer |
|
Contact |
Person |
Person |
Contact |
Person |
Person |
|
Service account |
Financial account |
Policy |
Policy |
Service account |
Contract |
|
Asset |
Asset |
Policy details |
Plan |
Asset |
Asset |
Example: Using the Account entity for your Customer accounts
In the Common Data Model ERD, top-level entities have a dark blue header that contains the logical name and class name. An entity contains fields and their data type. The following figure shows the Account entity:
The header of the Account entity shows its logical name, Customer, and the class name, Common-LDM-Entity-Account. The class key, AccountID, is the primary key and is an Identifier Field Type.
Fields define the entity and can reference data from another entity or Data Object. In the diagram, fields that begin with a period [.] indicate Embedded Data that the system can reference by using [.]. For example, the .AddressList field retrieves an address from the Contact methods object.
For example, a customer, Laura Smith, has an account with a company that sells telecom services. The following figure shows how the Account entity fields map to a record for the Laura Smith account:
In this scenario, the Account entity represents a customer account. The fields represent the data that make up an account record:
- The .Contacts field connects to the Contacts entity, which contains information for the people associated with the account.
- The address, phone, and email fields reference other Data Objects.
- The ServiceAccounts field references the Service Accounts entity, which contains information about the services associated with the account. Laura Smith subscribes to the Business Choice plan, a mobile phone and internet service.
The entities in a logical Data Model, such as Account, Contact, and Service Account, specify the data relationships so you use the actual data in multiple entities and multiple Cases. The actual data can be stored on different physical sources.
Embedded Data Objects
In the ERD, Embedded Data Objects have a light green header that contains a logical name and class name. The class key identifies the primary key and uses the Identifier Data Type. Data Objects describe a set of related fields. Fields in a Data Object indicate their Data Type and do not begin with a period, because the fields exist on the Data Object.
The following figure shows how the Account entity uses the .PaymentMethodList field to connect to the Payment methods object:
The Payment methods object stores the records that define various methods of payment, such as credit cards and checking accounts that are associated with each account. The payment method field in Account references a list of payment methods defined by the Payment methods object.
Field types for data relationships
In Pega Platform™, you create data relationships by using a set of specialized Field Types. When deciding which Field Type to use, consider the sourcing of the data for which you want to establish a data relationship.
To keep data scoped to the Case, use an Embedded Data Field Type. If the Data Object must come from an external source, use a Query or Data Reference Field Type instead.. The following Field Types are available for establishing data relationships:
- Embedded Data: An Embedded Data Field Type is used when a Data Object is within the context of an entity. The ERD marks Embedded Data relationships with a period to indicate that you can reference attributes in the related Data Object from the entity (for example, .AddressList).
- Query: A Query Field Type references a Data Page that retrieves data from a specified data source and caches that data in memory. For example, the Accounts entity uses a query field to display information about associated service accounts.
- Data reference: A Data reference Field Type passes data from entity to entity. Data reference lists help you source data from your application and display that information in a table where every row represents a field in a record, or a combo box. For example, a Transactions data reference can list all the transactions for a given Service Account.
Data Objects in the Common Data Model
As you develop the data model for your application, consider the entities and data relationships that best fit your data. If needed, consider where to extend the Data Model to add your Data Objects.
For more information, refer to the "data dictionary" document that describes the entities and objects in the Common Data Model.
This Topic is available in the following Module:
- Entities v1
If you are having problems with your training, please review the Pega Academy Support FAQs.
Quer nos ajudar a melhorar esse conteúdo?