Their dispute team works on a few case types including the SD dispute case type
We’ve created a configurable GNW page for the managers to assign which queue under which case type each user should be given, along with the priority for each etc.
When a user clicks on the GNW button, they should be given the cases under a particular work queue, based on the priority set by the manager. Once they exhaust the number of cases they were assigned in one work queue, they will move on to the next, on the click of G NW
This works for the other case types as GNW is based on the assignment (under each queue) and these case types typically only have one assignment open at a given t ime
The issue is that when it comes to the SD case type, the overarching requirement is that one user should work on one claim and all its disputes from end to end, regardless of whether they take a break or need time for investigation (unless reassigned by a mana ger)
If we configure GNW to assign individual assignments (like the other case types), this wouldn’t work as one person should work on one full claim
The caveat for the SD cases, however is that some assignments under the claim/dispute should not be picked up for GNW such as API error assignments, write off approvals for managers/users outside their access group etc.
Have you considered an approach where you route the claim via GNW rather than the dispute? I think that should address your issue.
General Functional Arch:
Route claims to a work basket that GNW draws from
Route Disputes to a work basket that users have “access” to but GNW does not draw from.
User presses GNW and is routed a claim. The user sees all the sub cases and cannot advance the claim until all sub-cases (disputes) have been resolved.
I’m not an SD expert, so can’t say for sure this approach is appropriate, but it’s what came to mind as a potentially simple solution!
For the existing case types, the current Get Next Work (GNW) implementation operates at the assignment level, selecting the next eligible assgnment from the configured work queues based on the manager-defined queue priorities. This approach is suitable because these case types typically have only one active assignment at any point in time.
The SD dispute case type requires a different allocation model. A single claim may have multiple disputes and multiple assignments that are created over its lifecycle. The business requirement is that ownership is maintained at the claim level, meaning the same operator should continue processing all eligible work for a claim until it is complete or explicitly reassigned by a manager.
To support this, the GNW implementation for SD cases should operate at the claim level rather than directly selecting assignments. The proposed processing flow is:
Determine the user’s configured work queues in priority order.
Check whether the user already owns an SD claim with outstanding actionable work. If such a claim exists, return that claim instead of allocating a new one.
If no owned claim exists, search the configured work queues (in priority order) for the next eligible unowned claim.
Assign ownership of the claim to the current operator.
Identify the next actionable assignment within that claim by excluding non-business assignments such as API error handling, technical/system-generated assignments, manager-only approvals, or assignments outside the operator’s access.
Open the identified assignment for processing.
This approach allows the existing queue prioritisation framework to remain unchanged while introducing claim-level ownership for SD cases. The assignment eligibility criteria should ideally be configurable (for example, via assignment type or a dedicated eligibility flag) to avoid hard-coded exclusion logic and simplify future maintnance.
The result is a GNW implementation that preserves end-to-end ownership of SD claims, prevents multiple operators from working on the same claim concurrently, and ensures only business-relevant assignments are surfaced to users while tecnical or administrative assignments continue to follow their existing routing behaviour.