Inclusive and exclusive queries
Scenario
Suppose a case needs to be reviewed by multiple independent reviewers. It can be solved in the following ways:
- Create a child case for each reviewer
- Create the same case with Split For Each for each reviewer
Assumption: When a review work queue assignment is fetched and moved to the reviewer’s worklist, the reviewer is immediately persisted as the child case’s reviewer work party, for example, pyWorkParty (Reviewer).
The parent of the case that the work queue assignment references should not match any parent of a child case that the reviewer has previously fetched.
- A child case is created for each of the N-required reviewers. The initial assignment in each child case is a work queue assignment. Each reviewer asks the system to pull a Review work queue assignment into their worklist.
- In other words, if sub-flows are created by using Split-For-Each instead of spinning off child cases, the following query prevents the same reviewer from using GetNextWork to pull work queue assignments for a case that the reviewer has already.
Solution design
select pzInsKey from |
Suppose that the case is two levels above the case to be fetched by a reviewer. Cases do not possess a pxCoverCoverInsKey
property. Still, you can define that property but use a more meaningful property name. If the case to be reviewed is a Claim, you want to define a work pool-level property named ClaimKey. The parent and grandparent Claim case sets ClaimKey equal to its pzInsKey and propagates ClaimKey property to its child cases. Likewise, those child cases also propagate the ClaimKey property to their child cases.
An alternative is to perform what is known as a hierarchical or recursive query, which each database vendor implements differently but is not supported by the Report Definition rule.
Interestingly if the goal is to avoid the same person reviewing the same case twice, and the case design does not involve child cases, the query above works just as well if the word Cover is removed. If subflows are created using Split-For-Each instead of spinning off child cases, the following query prevents the same reviewer, using GetNextWork
From pulling a work queues assignment for a case that the reviewer has already reviewed.
select pzInsKey from {Assign-WorkBasket} WB, {Org-App-Work-Review} REV where WB.pxAssignedOperatorID = [workqueue] and WB.pxRefObjectKey = REV.pzInsKey and REV.pxInsKey not in (select REV2.pxInsKey from {Org-App-Work-Review} REV2, {Index-WorkPartyUri} WP where WP.pxInsIndexedKey = REV2.pzInsKey and WP.pxPartyRole = "Reviewer" and WP.pyPartyIdentifier = OperatorID.pyUserIdentifier); |
This Topic is available in the following Module:
Want to help us improve this content?