Based on the requirements, I need to send notifications to specific work parties of child cases. The number of child cases can vary (e.g., 20, 30, or more).
I have implemented a Queue Processor to handle this asynchronously in the background. My question is: which is the recommended approach for sending the emails in this scenario ā SendSimpleEmail or CorrNew?
CorrNew is more suitable for enterprise-level implementations as it supports Pega correspondence rules, maintains email history/audit, works well with work parties and case context, and provides better maintainability and scalability. SendSimpleEmail is generally preferred only for lightweight or temporary email use cases without correspondence tracking requirements.
corr is the standard and scalable Pega approach for correspondence handling because it:
I have a question regarding the logic of the CorrNew activity.
In my scenario, I need to send emails to two specific Work Parties. From the documentation, I understand that I should use the parameter To_PartyRoles, specifying multiple roles separated by a comma when needed.
However, I am facing some confusion because, as shown in the screenshots, the parameter PartyRole appears to be mandatory in the activity configuration.
Could you please clarify how to correctly configure CorrNew in order to send the email to multiple Work Parties? Should both PartyRole and To_PartyRoles be used together, or is there a recommended approach to handle this scenario?
Iām not sure why PartyRole is Mandatory, However, the Java step in CorrNew activity reading from To_PartyRole and delimeter with comma to send teh emails.
Based on my testing, this behavior seems inconsistent with the documentation. When the PartyRole parameter is left empty, the process goes into a Broken Process state, as the system effectively treats this parameter as mandatory.
For this reason, it appears that in practice the PartyRole parameter must always be provided, even when using To_PartyRoles. It would be helpful to confirm whether this is the expected behavior or a potential issue, ideally by someone from the Pega product team.