We have encountered a scenario where the front-end team is responsible for creating cases with some initial processing details. These cases typically around 500 to 600 per day are then assigned to a work queue for the backend team to process.
The backend team handles these cases by cherry-picking from the queue. However, a challenge arises when they are asked to prioritize a specific case. Given the current setup, locating a particular case in the work queue can be difficult.
Pega recommends setting the ‘maximum number of rows to retrieve’ to 500, with no pagination. This means if the case in question falls outside that 500-row limit, it won’t be visible or searchable through the standard view.
To address this, we explored using a pagination activity. With this configuration, Pega fetches 10 results at a time. As users navigate through pages, previous results are discarded and the next set is displayed. While this allows users to search within the visible range, appending results to a separate page for broader visibility could lead to performance issues if the number of records grows too large.
Has anyone implemented a similar solution or found an effective approach to handle this kind of scenario? We’re looking for suggestions or best practices that could help us improve the searchability and performance of our case handling process.
@mashwaniYes, best practice is to keep results under 500 or use pagination. You should explore option of adding search criteria to find a specific case if the table (where you display the cases) specific column filter is not enough. The search fields can be used to perform more complex/advanced search.
Also I noticed that you are calling the report from an activity instead of a data page. Any reason for that?
@P_PRATIM Thanks for your response, yes we have given the custom search option for earching the case. This was for the work queue where the case is getting assigned and back office user will be picking the cases to process.
Regarding the data page, this was OOTB configuration in the Smart Dispute for work queue where report has been configured and we didn’t change to data page.
@mashwani You seem to be looking at this from a more technical solution perspective. However, my question would be why that specific case (or some other cases) require cherry picking. Question what is so special about these cases. Maybe setting SLAs and proper urgency might help out with identifying these cases, so that long term cherry picking is not required anymore and you can just use features like ‘Get Next Work’?
