We have a requirement to implement Get Next Work functionality that executes based on the work queues.
For example, we have a landing page that displays all cases belonging to work queue A, and another landing page that displays all cases belonging to work queue B.
Both landing pages should include the Get Next Work event, but the retrieval must be restricted to work queue specific to the corresponding landing page.
The current out-of-the-box Get Next Work functionality is generic and retrieves work items based on the operator profile setup. Our requirement is to customize this behavior so that it filters by work queues.
use one custom Get Next Work flow for both landing pages by saving the standard GetNextWork rule from Assign-Workbasket into your application ruleset and adding a filter for the required work queue. Pega allows the Get Next Work algorithm to be customized, so this is the right place to control which assignment is picked. On landing page A, pass work queue A; on landing page B, pass work queue B. In the customized rule, return only assignments from that passed work queue, then open the highest-priority item from that queue. This removes the generic operator-based behavior and makes each Get Next Work button pull work only from its own landing page queue.
Thanks Sairohith for the response. But, this is required to build in pega constellation and it doesn’t have flow. instead, enable/disable option in landing page and it calls GetNextWork activity from Work- level
To solve this in Constellation can you try override the GetNextWork activity in your application’s work class to include a filter for specific work queues. Since the landing page toggle triggers this activity, modify the logic to identify which page is active and use the corresponding Work Queue name as a filter. You should update the activity’s retrieval step to query assignments exclusively from that specific queue instead of following the default operator profile settings. This ensures that clicking the button on Landing Page A only pulls work items from Queue A and ignores other unrelated queues. By specializing this activity, you replace the generic system behavior with a targeted process that respects the context of your individual landing pages, please let me know if this got fixed, thanks
