Skip to main content
We're trying to determine best practices for setting up destination queues.

1. If we switch to dynamic queues with a low refresh interval (such as once an hour), what's the performance penalty for that? We typically have fewer than a dozen users in a queue.

2. What are the pros and cons of "Create single Activity Instance for Queue"? Supposedly the single instance is particularly suitable for call centers, but the documentation doesn't say why. We typically use only one slot per activity.

Thank you!
1. If we switch to dynamic queues with a low refresh interval (such as once an hour), what's the performance penalty for that? We typically have fewer than a dozen users in a queue.
As apposed to what? Normal destination queues with high refresh intervals?
I don't think you'll see any performance impact depending on the number of destination queues you're using. My personal opinion is that destination queues should only refresh once every 24 hours - When users are added and removed from AD/SQLUM groups, the administrator should do a manual refresh of the destination queue. Note that the only real difference between normal and dynamic destination queues is in the fact that dynamic destination queues will add and delete worklist items for new and/or deleted users in RUNNING process instances. Normal Destination queues will only add/remove worklist items for users in NEW process instances.

2. What are the pros and cons of "Create single Activity Instance for Queue"? Supposedly the single instance is particularly suitable for call centers, but the documentation doesn't say why. We typically use only one slot per activity.
This functionality limits the number of worklist items created e.g. in a call center where you've got 20 agents answering calls, K2.net Server will create 20 worklist items - one for each user. With this option selected however, only 1 worklist item will be created for the queue i.e. making the queries against the K2 database's worklist table a LOT quicker.

Hope this helps,
Ockert

Exactly what I was looking for; thank you!
What is the downside of always creating 1 worklist item for non-queued groups?

e.g. 3 slots each with 3 separate defined user.

If it's not a queue we couldn't use the Single Activity feature even if it's 1 slot.

What happens when I use Single Activity, but turn off dynamic queues?
Does that become dynamic queues without manually refreshing the queue??
Hi Peter,

Not sure I understood the questions fully but I'll try to answer some of it...

What is the downside of always creating 1 worklist item for non-queued groups?
e.g. 3 slots each with 3 separate defined user.
The downside is data volume which could cause performance problems. With normal users and groups defined in the Destination rule, the number of worklist items created will be the same as the number of destination users - irrespective of number of slots. Now, for a 3 user - 3 worklist item scenario it's not really a problem but in a typical call centre environment you'll have something like 200 process instances a day each being routed to 20 call centre agents creating 4000 worklist items per day. This can very easily run into 100s of 1000 worklist items in the K2 database which slows down sql queries dramatically.

If it's not a queue we couldn't use the Single Activity feature even if it's 1 slot.
True - as stated earlier, the number of worklist items created is NOT a function of number of slots but rather a function of number of destination users.

What happens when I use Single Activity, but turn off dynamic queues?
Does that become dynamic queues without manually refreshing the queue??
Not sure (need to test) but I would think that this will almost work the same as dynamic queues in that a user added to AD will also be able to action a worklist item - given that you have manually or automatically refreshed the queue. If the queue has not been refreshed, K2.net Server will not know anything about the user.

HTH,
Ockert

Reply