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.
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?