John Lordo (JohnLordo)
Eventus Solutions Group
Senior Architect
Eventus Solutions Group
JohnLordo Member since 2020 3 posts
Eventus Solutions Group
Posted: November 24, 2020
Last activity: December 2, 2020
Posted: 24 Nov 2020 18:47 EST
Last activity: 2 Dec 2020 10:32 EST

Pega Customer Service Contact SOR Implementation Layer issue(s)


We are building an implementation layer on Pega Customer Service 8.5 using Pega as the SOR for contacts. Suggestions from this questions have been followed as well: https://collaborate.pega.com/question/extending-organisation-data-class


Created a class Org-Data-Contact, with direct inheritance to PegaCA-Interface-Contact. The new class is mapping to a table in CUSTOMERDATA schema.

Class Inheritance

Class DB mapping


Also, we have setup all specialized OOTB DCR data transforms to ensure runtime uses Org-Data-Contact as the class for contacts

  • Declare_CAApplicationSettings.AppInterfaceContactClass
  • Declare_CAApplicationSettings.InterfaceContactClass

When we create contacts, e.g. from the OOTB “CPMNewContact” flow action, we see the Org-Data-Contact instance created in our own layer. This portion is working as expected.

We have not specialized any of the report definition or other rules from PegaCA-Interface-Contact class, as we are expecting to reuse them as is.

This is causing issues with multiple OOTB features.



For example, OOTB Inbound Correspondence cases (PegaCA-Work-Interaction-InCorr) skip the “Search Contact” assignment if a match is found using the sender email address of the incoming email.

Flow Name: AppContactSearch (PegaCA-Work-Interaction-InCorr)

Flow AppContactSearch


Activity: CPMFindContactByEmail (PegaCA-Work-Interaction-InCorr)


Activity CPMFindContactByEmail

Rule resolution picks the OOTB report definition PegaCA-Interface-Contact.CPMFindContactByEmail and executes it.

This report is not reporting on descendant class instances, and therefore not able to find our instances of Org-Data-Contact class.

Report Definition CPMFindContactByEmail


Even though a contact with the matching email address exists in the database, the “Search Contact” assignment is never skipped.

All other processes that rely on report definitions from the PegaCA-Interface-Contact class are having the same issue. Each of those report definitions do not report on descendant classes.


This forces us to ruleset specialize all of them for the sake of enabling reporting on descendant class instances, so that Pega Customer Service OOTB functionality works in the implementation layer.

We expect this to possibly cause issues when we upgrade to newer versions of Pega Customer Service, as additional OOTB features or changes would then need to be manually retrofitted into our ruleset specialized rules.

Question for Discussion:

Is there something we are missing or not implementing as expected or would it be preferable for the OOTB rules to report on descendant classes as well to foster implementation layer reuse?

Thank you upfront for sharing your thoughts.

Pega Customer Service 8.5 Reporting