My team and I are working on a case type which included a duplicate check in between the first and second steps of a multistep form. The case type we are working on inherits from another case type in our application due to the highly similar data models. The new case type we are working on routes the multistep form to a work queue for processing and completion. The duplicate check configured in this new case type hinges on two properties, so it’s processing should be rather straightforward. However, when I go to test the case type, once I make it through the first step in the multistep form to the duplicate check a Broken Process assignment comes up. When I click “Go” on the Broken Process assignment an error is shown stating “Unauthorized access for the given parameter ID”. The case type that this new case type inherits from does not have any issues with is duplicate check. Any ideas on how to debug this or resolve this issue would be greatly appreciated!
Update: I tweaked the duplicate conditions slightly and received a new error message as depicted in dupequestion4.png. Does this error message mean it is trying to reference an Operator record called “Releasers”? Releasers is the name of the work queue the steps in this multistep form are routed to.
@TessPorter It seems that the issue with the broken process and unauthorized access error might be related to permissions or context between the parent and child case types. Since the new case type inherits from another, there could be an issue with how the properties or access roles are being inherited, especially for the duplicate check step. The error message “Unauthorized access for the given parameter ID” suggests that the duplicate check might be trying to access a parameter or property for which the current case type does not have the required permissions. To debug this, you could start by checking the security settings for the new case type and ensuring that the properties used in the duplicate check are accessible. Additionally, verify that any access control settings on the parent case type have been properly inherited, or if any explicit access needs to be set up for the new case type
@Sairohith Good Afternoon Sairohith! Thank you for your response to my question. I validated that the properties being used in the duplicate check are accessible in the the new case type. In regards to what you mentioned regarding access control settings, are you referring to work parties? If not, can you explain more explicitly which access control settings you are referring to?
@TessPorter In this case, I’m referring to access control settings that govern which users or roles have access to specific data or actions in the case. This could involve ensuring that the security settings for the properties used in the duplicate check are properly configured for the new case type. While work parties may play a role, the main focus should be on the access control settings for the case type itself, especially around the properties involved in the duplicate check. You’ll want to check if the new case type’s roles and security settings have been properly configured or inherited from the parent case type, and if necessary, update the access control for any specific parameters or properties being accessed during the check.
@SairohithWhere do I go to validate access control settings on properties involved in the duplicate check? Is that configured within the case type or the property rules?
@TessPorter Received the following explanation from Pega Support:
I believe the problem here is the multi-step form. Typically multi step forms meant to behave as a single task, broken up into several screens to be processed one after another by a single user, and the assignments for each screen are automatically assigned to that user (or in this case, the workbasket). When a duplicate search finds a duplicate case, it creates a worklist assignment for the user. Because of the multi-step form context being aligned to the workbasket, the process attempts to create a worklist assignment and fails because the multi-step form is assigned to the workbasket.
From case designer, adding a duplicate search step to a multi step form is not possible. While one can be added via the flow ruleform, the OOTB Duplicate Search subflow shape is designed to create a worklist assignment. I would recommend leveraging standard stage steps surrounding your duplicate search, rather than a multi step form. In my local testing, this approach did not encounter the same error.
If a multi step form is explicitly required in this scenario, you might be able to customize the OOTB pyDuplicateSearch flow for this case type to change it’s assignment’s routing configuration, however assistance with such customization would be outside the scope of a support requests.
