Integrating Common Data Model with existing systems of record

Step 1: Identify the Data Object for integration

Begin your implementation by identifying the specific data object that requires CDM integration. During this selection process, prioritize data objects based on business impact, frequency of use, and integration complexity. Focus on objects that will benefit most from the CDM's abstraction layer, which provides standardized access patterns while maintaining separation between your application logic and underlying data sources.

Consider the data object's role within your broader application architecture and how it connects to other system components. This analysis helps ensure that your CDM implementation creates a cohesive data management strategy rather than isolated integration points.

Step 2: Map Data Page dependencies

Examine the existing Data Pages associated with your selected data object to understand current data access patterns and dependencies. During this analysis, document how data flows through your current system, identify any existing transformation logic, and note performance characteristics of current data retrieval operations.

Pay particular attention to Data Page configurations, caching strategies, and any custom logic that handles data formatting or business rule applications. This understanding becomes crucial for maintaining functionality while transitioning to CDM-based data access patterns.

Step 3: Configure the Data Page integration

When you configure the Data Page integration you can use one out of two, mutually exclusive approaches:

Option 1: Use your existing Connector to load the Data Page

If you have existing connectors that successfully retrieve data for your current implementation, configure these connectors to work with CDM Data Pages. During this integration, you maintain proven connectivity patterns while gaining the benefits of CDM's standardized data structure and abstraction layer functionality.

This approach minimizes integration risk by building on established, tested connectivity while introducing CDM benefits incrementally. You preserve existing authentication, error handling, and performance optimizations that have been refined through operational experience.

Option 2: Update the Data object to use that Data Page

Alternatively, if you have existing Data Pages that can serve your CDM integration needs, modify your data object configuration to reference these established Data Pages. During this process, ensure that the Data Page structure aligns with CDM entity requirements and that any existing caching or performance optimizations remain effective.

This approach leverages existing data access infrastructure while adapting it to support CDM integration patterns. You maintain operational stability while introducing the abstraction layer benefits that CDM provides for future application development.

Step 4: Update mappings in Data Transform

Configure Data Transform rules to handle the conversion between your external system data formats and CDM entity structures. During this mapping process, implement both request and response transformations that ensure data integrity as information moves through the abstraction layer.

Focus on creating robust mapping logic that handles data type conversions, field name translations, and any business rule applications required for your specific integration scenario. The CDM framework provides auto-mapping functionality for common field types, but custom transformation logic ensures that complex data structures and calculated fields are handled appropriately.

Step 5: Iterate through remaining Data Objects

Apply this same systematic process to each additional data object that requires CDM integration. During this iterative implementation, you build a comprehensive data management framework that provides consistent access patterns across all your enterprise data sources.

As you progress through multiple data objects, look for opportunities to standardize transformation logic, optimize connector configurations, and establish reusable patterns that accelerate future integrations. The abstraction layer approach ensures that each implementation builds on previous work while maintaining flexibility for object-specific requirements.

A high number of out of the box features, as well as new features and enhancements have direct references to the Contact, Account, ServiceAccount and Asset properties, and the specific attributes in the properties presented in this section. If you choose not to implement these properties, it may lead to implementation risks and upgrade complications in the future.

Data objects from the Pega Common Application are essential because they are used throughout Pega Customer Service™ applications. For example, in the following screenshot, observe that the Interaction case includes a property for Contact. This property references the Contact data object in the Common Application.

Beyond these core properties, notice that Case Variants exist for each of them. They serve distinct roles in interaction and service case scenarios, and you must implement both the properties and their case variants without replacing or renaming them. The following table provides detailed information about each property in the Customer Service Infrastructure classes:

Entity properties (such as Contact or ServiceAccount) serve the same purpose in service cases as in interactions and must be implemented in service cases. The usage of Entity_Case properties (Contact_Case, Account_Case, ServiceAccount_Case and Asset_Case) in service cases differs from their usage in interactions. In service cases, these properties:

• Are used to edit and commit entity data to the System of Record. For example, the Contact_Case property captures updated names and commits them to the System of Record in the "Update Contact Name" service case.
• Use "copy" instead of "refer" configuration to store the updated entity data in the case which can be used for before-after comparison and for audit purposes. For example, in the "Update Contact Name" service case, the Contact property stores the original name while Contact_Case stores the updated name. These properties enable before-after comparison on the review screen, retaining this information in the case for future review or audit.
• Require population only for service cases that update one or more entities. For example, if a service case updates only contact details, ServiceAccount_Case, Account_Case, etc. are not needed on the service case.
• Should contain only updatable attributes, not complete entity property copies. Achieve this by using "Optional Data Mapping" data transform in the property rule. For example, if a service case updates first name, middle initial, and last name of the contact, specialize Data Transform MapEntityData in that service case class and set .FirstName, .MiddleInitial, and .LastName. This ensures the .Contact_Case page contains .FirstName, .MiddleInitial, and .LastName properties. This configuration is only possible from Dev Studio.

Properties are sourced using Data pages. If you have an existing connector, update the Data Page to use your connector. For example, the Interaction class includes a Contact property that uses the D_Contact Data Page. The following figure illustrates the property hierarchy connecting Customer Service interaction classes to Common Data Model entities:

When you create a different data layer extending the Common Data Model, ensure the page definition matches your creation but inherits from the Common Data Model. If you have a well-defined Data Model that does not easily map to Common Data Model structure, consider adding mapping layers that transform your existing model to the Common Data Model. This transformation is typically handled through response data transforms in data pages.