Case distribution

Case distribution involves how cases are assigned to an investigator’s private working pool.

Case distribution is based on a configurable case investigation menu, which is closely interconnected with the mandator structure, the users associated with the mandators, and their roles in each corresponding mandator. The case distribution mechanism can be intricate depending on the complexity of the mandator structure and the conditions that must be fulfilled.

The following diagram illustrates the case lifecycle:

Case generation process is: the case is generated and assigned to a case class. Then working queue conditions are evaulated and the case is inserted to a working queue. The case is pulled and assigned to a private queue. The case work can start.

Case generation is triggered either by model rules or by manual creation. Then, the case is assigned to a case class. The case then passes through the working queue assignment. The working queue definition requires the following items, which are relevant to the case assignment:

  • Selection of the mandator that the working queue is associated with.
  • Selection of the list of mandators corresponding to cases from mandators.
  • Insertion conditions from the available pull-down list, for example, case class, days since last action, and so on.
  • Prioritization setting for working queues if multiple working queues are associated with the same mandator.

The cases are then inserted into the working queues according to the conditions and in chronological order by oldest first, which is also indicated by the ascending caseID value.

The process of pulling a case from the public pool to the private pool (or work case) is as follows:

  • The working queues from the highest level mandator are evaluated first, following first the prioritization condition within the mandator. Hence, the working queue from the mandator with the lowest priority value is evaluated first. This can be counter intuitive because it is usually expected that the higher the priority the more relevant the issue is.
  • The working queue with lowest priority value from the highest level mandator then gets cases according to their definitions, mainly satisfying the criteria from the Cases from mandators field and condition section.
  • Then, the working queues from the same-level mandator but with higher prioritization get the cases as previously described.
  • Then, the working queues from the lower-level mandators are next in line during the evaluation procedure, following the same criteria as previously described. The process continues until the lowest level mandator is checked.

Important remarks:

  • A case can be assigned to only one working queue at a time. As a consequence, if all the cases were assigned to the top-level mandator, a situation might exist where there are working queues associated to lower-level mandators that have no cases assigned to them.
  • Cases that are not associated with any working queues are still accessible, however, not through the pull case method, but from the case selection/case search tabs. Therefore, it is recommended to configure the working queue to ensure that all cases get assigned. To prevent this, you can impose auto-escalation conditions on a transition.
  • If working queues are associated with the mandators that are at the same hierarchy level, the mandator that was defined first in the mandator structure is picked first for evaluation (by the lowest UID value).

Example

Assume that a mandator structure has the following hierarchy:

Mandator structure
  • A is the top-level mandator, followed by mandator B, C, D, E, and then mandator F, which was added last to the structure (hence with higher UID value).
  • Assume that there are three working queues:
    • Working Queue 1 is associated with Mandator B with priority 10.
      • With cases from Mandator C, D and CaseClassID 100.
    • Working Queue 2 is associated with Mandator B with priority 20.
      • With cases from Mandator D, E and CaseClassID 110.
    • Working Queue 3 is associated with Mandator F (priority irrelevant, as there is only one in this mandator).
      • With cases from Mandator F and CaseClassID 200.
  • Assume that the following 10 cases are generated (in chronological order):
    • CaseID 1-1: CaseClassID 100 to mandator C
    • CaseID 1-2: CaseClassID 100 to mandator C
    • CaseID 1-3: CaseClassID 200 to mandator F
    • CaseID 1-4: CaseClassID 100 to mandator D
    • CaseID 1-5: CaseClassID 110 to mandator D
    • CaseID 1-6: CaseClassID 110 to mandator E
    • CaseID 1-7: CaseClassID 100 to mandator D
    • CaseID 1-8: CaseClassID 200 to mandator F
    • CaseID 1-9: CaseClassID 100 to mandator C
    • CaseID 1-10: CaseClassID 110 to mandator E

The distribution of the cases starts with mandator A, which has no working queues defined. Then, mandator B is checked, which has WQ1 and WQ2. Applying the conditions from the definitions of the working queues, the 10 cases are assigned as follows:

  • WQ1 with CaseID 1-1, 1-2, 1-4, 1-7, 1-9
  • WQ2 with CaseID 1-5, 1-6, 1-10
  • WQ3 with CaseID 1-3, 1-8

Since WQ1 has lower priority than WQ2, the cases from WQ1 are pulled (distributed) first, followed by the cases from WQ2.

Because Mandator F was created later than B, it has an internal UID value higher than the one of mandator B. Therefore, it is evaluated later, even though it is on the same hierarchy level as B. Therefore, the cases from WQ3 are pulled last.

Assuming that only one investigator has access to WQ1, WQ2, and WQ3, the cases are distributed to his work case in the following order:

1-1, 1-2, 1-4, 1-7, 1-9, 1-5,1-6, 1-10, 1-3,1-8