Context:

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

Overview:

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

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.

Issue(s):

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)

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

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.

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.

Workaround:

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.