K2.net 2003 with SP3 introduces an enhancement around Destination Queue user management at runtime. Currently in K2.net we have scenarios where Destination Queues resolve to large number of users creating a huge overhead on K2.net Server having to manage the activity instances representing the worklist items.

Introduction
 
K2.net 2003 with SP3 introduces an enhancement for Destination Queue user management at runtime. Currently in K2.net scenarios exist where Destination Queues resolve to multiple user groups which may be large depending on the number of users. This increases the operational overhead on K2.net Server because the activity instances representing the worklist items need to be managed. Currently K2.net Server creates an activity instance for each user belonging to the destination queue. The new feature, which is enabled at design time, has been added to the Destination Rules to force K2.net Server to create a single instance of the Activity shared by the user part of the destination queue. The new functionality is especially applicable for implementations where destination queues consist of many users and only one user is required to complete the task; which is commonly seen in Call centre environments.

  

A number of design considerations are required to implement this function properly as well as understanding the impact this might have on your current design.
 
Using the "Create single Activity Instance for Queue" option affects the following:
  • Activity Slots
  • Succeeding Rules
  • Line Rules
  • Email notifications (Client Events and Server Mail Events)
 
 
Enabling the "Create single Activity Instance for Queue" option:
The "Create single Activity Instance for Queue" option will only be available when the configured Destination Rule contains a Destination Queue
  • Create single Activity Instance for Queue - Disabled
  
 
  • Create single Activity Instance for Queue - Enabled
  
 
Runtime behavior
To fully understand the concept of "Create single Activity Instance for Queue" lets consider the runtime behavior of the K2.net Server when the option is enabled versus being disabled. The following section looks at various scenarios to illustrate how the feature works.
 
The affect that "Create single Activity Instance for Queue" has on Activity Instances (Slots)
The table below lists a number of scenarios including the outcome for the configuration. The scenarios are based on common example implementations and should be considered during the configuration of Destination Rules, Succeeding Rules, Line Rules and Activity Slots.
Assumptions:
  • Call Center Queue - This Destination Queue resolves to 10 unique users
  • Sales Queue - This Destination Queue resolves to 10 unique users
1)
Maximum number of Activity Instance (Slots) available during runtime: 10

Maximum number of Activity Instance (Slots) available during runtime: 1
2)
Maximum number of Activity Instance (Slots) available during runtime: 13

Maximum number of Activity Instance (Slots) available during runtime: 4
3)
Maximum number of Activity Instance (Slots) available during runtime: 20

Maximum number of Activity Instance (Slots) available during runtime: 2
 
The effect that "Create single Activity Instance for Queue" has on the behavior of Worklist item interaction
The management of the "Status" of a Worklist item is also affected by the use of this function, the following examples illustrates the expected behavior.
 
Scenario 1:
Assumptions:
  • Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy)
  • Create single Activity Instance for Queue - Enabled
  • Activity Slots - 3
1. Initial Status of Items2. Emile opened his Item
Christo
Emile
Jaco
Bob
John
Mandy
Available
Available
Available
Available
Available
Available
Christo
Emile
Jaco
Bob
John
Mandy
Available
Open
Available
Available
Available
Available
3. Christo opened his item4. Jaco opened his item
Christo
Emile
Jaco
Bob
John
Mandy
Open
Open
Available
Available
Available
Available
Christo
Emile
Jaco
Bob
John
Mandy
Open
Open
Open
Allocated
Allocated
Allocated
 
Scenario 2:
Assumptions:
  • Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy)
  • Create single Activity Instance for Queue - Enabled
  • Activity Slots - 3
1. Initial Status of Items2. John opened his Item
Christo
Emile
Jaco
Bob
John
Mandy
Available
Available
Available
Available
Available
Available
Christo
Emile
Jaco
Bob
John
Mandy
Available
Available
Available
Allocated
Open
Allocated
3. Emile opened his item4. Jaco opened his item
Christo
Emile
Jaco
Bob
John
Mandy
Available
Open
Available
Allocated
Open
Allocated
Christo
Emile
Jaco
Bob
John
Mandy
Allocated
Open
Open
Allocated
Open
Allocated
 
Scenario 3:
Assumptions:
  • Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy)
  • Sales Queue - This Destination Queue resolves to 3 unique users (Sheri, Brian and Joe)
  • Create single Activity Instance for Queue - Enabled
  • Activity Slots - 3
1. Initial Status of Items2. Sheri opened her item
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Available
Available
Available
Available
Available
Available
Available
Available
Available
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Available
Available
Available
Available
Available
Available
Allocated
Allocated
Open
3. Bob opened his item4. Jaco opened his item
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Available
Available
Available
Open
Allocated
Allocated
Allocated
Allocated
Open
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Allocated
Allocated
Open
Open
Allocated
Allocated
Allocated
Allocated
Open
 
Scenario 4:
Assumptions:
  • Call Center Queue - This Destination Queue resolves to 3 unique users (Bob, John and Mandy)
  • Sales Queue - This Destination Queue resolves to 3 unique users (Sheri, Brian and Joe)
  • Create single Activity Instance for Queue - Enabled
  • Activity Slots - 3
1. Initial Status of Items2. Christo opened his Item
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Available
Available
Available
Available
Available
Available
Available
Available
Available
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Open
Available
Available
Available
Available
Available
Available
Available
Available
3. Emile opened his item4. Jaco opened his item
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Open
Open
Available
Available
Available
Available
Available
Available
Available
Christo
Emile
Jaco
Bob
John
Mandy
Brian
Joe
Sheri
Open
Open
Open
Allocated
Allocated
Allocated
Allocated
Allocated
Allocated
 
Scenario 5:
Assumptions:
  • Call Center Queue - This Destination Queue resolves to 6 unique users (Bob, John, Mandy, Brian, Joe and Sheri)
  • Create single Activity Instance for Queue - Enabled
  • Activity Slots - 3
1. Initial Status of Items2. Joe opened his Item
Bob
John
Mandy
Brian
Joe
Sheri
Available
Available
Available
Available
Available
Available
Bob
John
Mandy
Brian
Joe
Sheri
Allocated
Allocated
Allocated
Open
Allocated
Allocated

 

Important: Although the number of available Activity slots has been set to 3, K2.net Server overrides this setting and will only allow 1 slot for the destination queue. This behavior must be taken into consideration during configuration of the Succeeding Rules and Line Rules.

 

 

General Design Considerations
This new functionality can cause unexpected behavior during the execution of a process instance. Each point mentioned below requires a specific user context to complete the associated step. The implementation of "Create single Activity Instance for Queue" does not expose the user context until the participant takes ownership of the task
 
Mail Events (including Client SMTP Notification Message and Mail Escalation)
The runtime implementation of this forces K2.net Server to create a single Activity Instance and assign that instance to the Destination queue rather that the actual users. The only time that the item is associated with a specific user is when the user opens the item using the K2.net Worklist or custom implementation of the K2.net Worklist. The result of this can cause mail events using the "Send to Destination User" to fail. This can cause a runtime exception that will be logged in the K2.net Error Profile.

  

 
Redirect Escalation
The Redirect Escalation Wizard allows Worklist Items to be redirected to the current user's manager once a specified time has elapsed. Items NOT allocated to a specific user will not be redirected. This can cause a runtime exception that will be logged in the K2.net Error Profile.
  
 
K2.net InfoPath Processes
The "Create single Activity Instance for Queue" functionality is NOT COMPATIBLE with a K2.net InfoPath process. An InfoPath enabled process creates a document for each participant associated with the client activity. Since the task is associated with a destination queue and not a user, the creation of the document requires the associated user context which will not available.