Configure Pega Sales Automation as a master system of record

From PegaWiki
Configure Pega sales automation as a master system of record / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Configure Pega Sales Automation as a master system of record

Description Best practices for configuring the system of record in Pega Customer Relationship Management suite
Version as of 8.5
Application Pega Sales Automation
Capability/Industry Area Sales Automation



This document is intended for technical architects who design and configure the Pega Customer Relationship suite of applications. This document describes the best practices required to use Pega Sales Automation as a master system of record for customer data in a Pega Customer Relationship Management suite of applications.

Overview[edit]

Pega Customer Service and Sales Automation applications have pre-configured system of records. Pega Marketing has a flat table structure for storing customer data that is derived from various external system of records. Pega Customer Service and Sales Automation have their own physical and logical data models, and are designed to synchronize data in real time.

Pega Sales Automation is used as the system of record for the entire Customer Relationship Management suite of applications if:

  • Customer is already using the application in a production system
  • Customer prefers the definition of the application's physical data structure

Customer Service and Sales Automation data layers[edit]

The Pega Customer Service application integrates with any external system of record for necessary data objects such as contact, organization, and account. The data objects have direct inheritance from the Data- class.

The data objects are treated as cases, with a direct inheritance from the Work- class. Different logical and physical models ensure the difference in data object design, as either data or a case.

Physical and logical layers[edit]

To perform CRUD operations, data objects must be configured to point to the Pega Sales Automation system of record . To illustrate this concept, this topic describes the physical and logical layers of two data objects: contact and address.

Contact and address data objects in Pega Customer Service[edit]

In the Pega Customer Service application, contact and address data objects are represented by the following classes. These classes connect to a database table for physical storage, and use a reference page as the method to perform CRUD operations.

Class Database Table Reference page
PegaCA-Interface-Contact Contact pyWorkPage.Contact and D_Contact_Details
PegaCA-Interface-Address Address D_Contact_address

Contact and address data objects in Pega Sales Automation[edit]

In the Pega Sales Automation application, contact and address data objects are represented by the following classes, which connect to a database table for physical storage. Because the data objects are treated as cases, the physical tables have BLOB (pzpvstream).

Class DB table
PegaCRM-Entity-Contact crm_entity_contact
PegaCRM-Index-Address CRM_index_address

Recommended configuration[edit]

Updating the contact data object in Pega Customer Service[edit]

Compare and identify missing properties[edit]

Compare the Pega Sales Automation contact table (in addition to other related tables such index tables) with the Pega Customer Service contact table, and then add missing required columns to the Pega Sales Automation contact table and to other related tables.

Create a new contact data object in Pega Customer Service[edit]

Create a new PegaCRM-Data-Contact data class (any named class) with direct inheritance to PegaCA-Interface-Contact.

Create a new database table for data object mapping in Pega Customer Service[edit]

Create a new Data-Admin-Database-Table instance for the new data class, and map the class to the Pega Sales Automation contact table (crm_entity_contact).

Map columns to Pega Customer Service properties[edit]

As the logical layer attributes are different in both applications, map the Pega Sales Automation contact database table columns to the appropriate Customer Service contact data object attributes. This helps reduce rule overrides.

Update the external class mapping tab of the PegaCRM-Data-Contact class with column names from the crm_entity_contact table, and then map them to the Pega Customer Service contact data object properties. When the contact record is fetched from the Pega Sales Automation table, the Pega Customer Service application methods do not need to be updated. For guidance, see the following image.

DP CRM serviceproprties.png

Update contact object references in Pega Customer Service[edit]

Update rules used to perform CRUD activities for contact data by mapping the rules to the new data object class (PegaCRM-Data-Entity-Contact). The following rules are examples to consider updating:

  • D_Contact_Details
  • D_Contact_Party
  • pyWorkPage.pyWorkParty(Contact)
  • pyWorkPage.Contact

The following image shows an example of the CRMGetContactInfo report definition updated to use the new data object class as its Applies To class. This configuration is required to take advantage of the external class mapping described previously.

Note: Use dynamic class referencing (DCR) to map the pxObjClass property in the filter criteria to the Pega Sales Automation contact class (for example, PegaCRM-Entity-Contact).

Creating a new contact data object in Pega Customer Service[edit]

Open the AppNewContact activity[edit]

When you create a contact from a Pega Customer Service interaction case, the contact details need to be saved to the Pega Sales Automation contact table. The commenting shown in the following image ensures that a contact created from Pega Customer Service is saved into Sales Automation contact table.

App new contact.png

Set the value of pzInskey to ContactId[edit]

In the new Pega Sales Automation contact case, set the value of pzInskey to ContactId on the Pega Customer Service interaction case.

When a contact record is created in Pega Sales Automation, a pzInsKey value is generated. Update the ContactId property in the pyWorkPage of a Pega Customer Service interaction case to use pzInsKey as a value in the CRMCreateContact activity. This configuration allows both the applications to refer to the same contact key.

Set the ContactId on the pyWorkPage of the Pega Customer Service interaction case to trigger the loading of ‘D_Contact_Details’, ‘D_Contact_Party’ data pages. The pyWorkPage.pyWorkParty(Contact) and pyWorkPage.Contact clipboard pages will be populated in the Pega Customer Service application.

Step 9 in the following image shows the pzInsKey mapping to the ContactId property.

In Pega Sales Automation, the CRMCreateContact activity saves contact records. In Pega Customer Service, this activity is called from the CPMAddContact flow.

By populating the following pages with the data from Pega Sales Automation contact tables, the header details and composites in Pega Customer Service will be populated with appropriate contact details: D_Contact_Details, D_Contact_Party, pyWorkPage.pyWorkParty(Contact), pyWorkPage.Contact.

You should check and update any rules that are involved in loading the contents of D_Contact_Details, because the data present in this page is propagated to the necessary clipboard pages.

CRM Set pzInksey.png

Comment out the step that creates an entry in the spine table[edit]

Comment out the step that creates an entry in the spine table, because that table is no longer required.

A spine table is a table that stores keys of an entity that is in multiple system of record tables. Since Pega Customer Service and Pega Sales Automation have two different system of record patterns, a spine table is used to match the keys of an entity. In this approach, there is going to be only one system of record, and there is no need to use a spine table. Comment out the step that creates an entry in the spine table. Similar changes might be required in the Pega Sales Automation application. The default behavior is that the composite is loaded in the contact record in the Pega Sales Automation application based on the entry in this table.

Updating the address data object in Pega Customer Service[edit]

Create a new address class in Customer Service[edit]

Create a new PegaCRM-Data-Address class (this can be any named class) with directed inheritance to the PegaCA-Interface-Address class.

Connect the data object to the physical database[edit]

Connect the data object to the physical database table connection in Pega Customer Service. Create a new Data-Admin-Database-Table instance for the new class, and then map that to the Pega Sales Automation address table named CRM_Index_Address.

Map columns to address properties[edit]

Update the external class mapping tab of the PegaCRM-Data-Address class with column names from the CRM_Index_address table to the address data object properties for the Pega Customer Service application. Once this is complete, when an address record is fetched from the Pega Sales Automation address table, no overrides are required in the Pega Customer Service application.

PegaCRM Edit class.png

Update address object references[edit]

Populate D_Contact_Addresses with the address data from the Pega Sales Automation address table. To do so, update the report definitions in Pega Customer Service to use the new PegaCRM-Data-Address as the Applies To class.

If external mapping done in the PegaCRM-Data-Address class record is not enough to map the Pega Sales Automation address columns to Pega Customer Service properties, then add data transform rules to map address table columns from Pega Sales Automation to the Pega Customer Service address data object properties.

The address details captured during contact creation for an interaction case are saved in the Pega Sales Automation address table. Comment out the steps from the AppNewContact activity as shown in the following image. Doing so ensures that the address details are persisted only in the Pega Sales Automation tables.

Appnewcontact.png

Update Dynamic Class References[edit]

Once new data object classes are created as explained earlier in this document, update the dynamic class referencing (DCR) settings so that the new data object classes are used as a reference in executing rules.

To update DCR settings, update the CPMInterfaceLayerSetting data transform with newly created data object class definitions so that the rules, such as report definitions and others present in that new class, will be picked up dynamically. The following image shows the data transform rule.

Searching for a contact stored in Pega Sales Automation in order to launch an interaction[edit]

Follow this procedure to update rules to search for a contact record from the Pega Sales Automation contact table during a Pega Customer Service interaction.

D_Search_Customer is the data page that shows search records in the new phone call flow. To fetch the appropriate search results, save data pages and report definitions to the new address data object class that you created for Pega Customer Service.

For example, CPMContactsByAccountNumber is a report definition used to fetch records during a search, based on the account number and last name fields. This report definition should be saved into a new data object class, and then modified as needed. The following image shows an example of the report definition rule.

Marketing offers[edit]

In Pega Customer Service, the Next Best Action (NBA) widget suggests targeted marketing offers that a customer service representative (CSR) can present to a customer. These actions are triggered from Pega Customer Decision Hub. Pega Customer Decision Hub uses customer data to analyze the next set of actions. The NBAWidget uses TargetContactId as a property, and that property contains the contact key. Map the TargetContactId property to the ContactId property value, so that the NBA-related data pages can execute without requiring updates to these rules.

When you create a contact record in the Pega Sales Automation contact table, you can set TargetContactId to the value of the ContactId property in the CRMCreateContact activity. The following image shows the step where you configure that property mapping.

Marketing offers.png

Displaying customer data in the customer composite[edit]

The ContactId changes described earlier in this document make it possible for the report definitions used in the customer composite widgets to fetch the customer composite data. In the Interaction Portal, the customer composite shows the entire customer history of touchpoints captured in a summarized fashion, including customer and account details, recent cases, recent interactions, marketing history, account transactions, and statements.

Conclusion[edit]

Deciding on the most appropriate path for implementing a master system of record for your Pega Customer Relationship Management applications requires careful consideration. This document outlines and illustrates the best practices a technical architect should consider when planning for a master system of record for a Pega Customer Relationship Management suite. By updating a few rules, you can update the Pega Customer Service application to use Pega Sales Automation as the primary system of record for customer data.