Working with Queues in Dynamics

I have always been a bit cautious of the queues in Dynamics since I could not fully understand when to use them. I don’t know, somehow my technical knowledge of what they are just did not materialize into a clear understanding of what to do with them.

This is until on one project business users just said “we will be using queues”. And on another project somebody asked if they should be using queues. So, if you are in the same boat, I’m hoping this post will help.

Basically, queues are called queues since you can add items to them. Yet it’s not just one specific entity type per queue – you can add different entities to the same queue (as long as queues have been enabled for the corresponding entities).. which that makes queues very different from the regular entity views.

Now let’s say you have queues and there are some items in them – you can look at those queues from different perspectives:

You can look at the items you are working on:

Or you can look at all items:

And, as you can see above, you can either look at the items in all queues (which includes public queues and those private queues you are a member of), or you can look at the queues you are a member of.

What’s involved there is 3 different entities:

• There is an entity that can be added to the queue (case, for example)
• There is a Queue
• And there is a “Queue Item” entity which links an “item” to a “queue”

 

There can be only one Queue Item per record – you can’t put the same record (case in this example) in more than one queue.

This is where things get a bit confusing from the terminology standpoint. I think I’m going to use “Queue Item” for the queue item entities, and I’m going to use “item record” for the actual cases (or other records) added to the queue and referenced by the queue items.

Also, that Queue Item entity has an interesting property which is saying if a queue item is being worked by somebody:

If an item is being worked by you, you’ll see that item in the “Items I am working on” view.

If an items is not being worked by anybody, you’ll see it in the “Items available to work on” view.

Once you’ve selected an item in the list, you can use “PICK” button from the command bar. That button gives you a choice of either removing queue item from the queue or keeping it there:

But, if you choose not to keep that queue item in the original queue on the screen above, which queue is it going to be in then? And is it going to be anywhere at all?

Hope you remember that every user and/or team would normally have a default queue:

All the records assigned to the user will automatically go to that queue (even if they used to be in a different queue). Actually, it’s also where the records will be placed in the “pick” scenario above if you choose not to keep queue items in the original queue when using “pick” option.

But, it’s only if the entity is configured that way – cases are, by default, but they don’t have to be, so what if we re-configure that setting on the entity configuration screen (and publish etc)?

After some experimenting, I think here is how “PICK” really works:

• It will assign an record (case) to you
• Once the record (case) is assigned to  you, and if you opted to remove queue item from the Queue, the queue item will either be deleted, or it will be re-linked to your private queue (depending on the entity configuration – see the screenshot above)
• If you opted not to remove that queue item from the Queue, the queue item will still be linked to the original queue
• In either case, if there is still a queue item, that queue item will be updated so that “worked by” will be showing your user name

So, then, the basic scenario for working with queues is, probably, this(Assuming your entities “automatically move .. to the owner’s default queue when a record is created or assigned”:

1. Make sure your entities are configured so that records move to the owner’s default queue when a record is created or assigned
2. Start looking at the queues screen periodically (maybe create a dashboard, too)
3. If you want to see what you are working on, just pick “Items I am working on” view, and select all queues. That’s your current work
4. If you need more work, look at the “Items available to work on”, select one, and PICK it from the queue. Do not remove that item from the queue. Corresponding record will be assigned to you, it will stay in the current queue, and a queue item will be “worked by” you
5. Once you are done working on the item, either remove it(no more work.. closing) or release it (somebody else will probably need to pick it). As an option, you can first add it to a different queue, and, then, release

 

There can be a few variations depending on the configuration settings and selections discussed above, but, basically, it’s all about working with those queue views. Those views become your “home page” since you don’t even need to look at the individual entity views to see your workload.

However, what remains is the question of control. As in, how do we ensure that an item has not been forgotten/left unattended for too long? What if nobody wants to pick an item from the queue? Or what if there is a record which, somehow, just has not been added to a queue at all?

It’s a 1:N relationship between entities and queue items in Dynamics:

So you cannot, really, set up a workflow on the case entity to watch for the queue item changes. You can create a workflow on the queue item entity, though, so, through the queue item ,you may be  able to update a field on the case.. or on another queue-enabled entity. Then you can use that field to run notification workflows, or to build views, etc. But you’ll have to do that separately for each queue-enabled entity, so this solution does not sound very promising.

And, actually, this is why the whole concept of SLA-s was introduced, but, somehow, it’s never been discussed in the context of the queue items. Even more, we cannot enable SLA-s for the queue items (unless we implement those SLA-s manually using different workflows etc)

Of course you can build a separate view to show you all queue items which have no “worked by” and which have not been modified for a few days.. But that’s not necessarily what you need either because there could be different conditions for different types of work(for different entities).

Maybe that’s the gap that has not been fully addressed yet? It seems for now that kind of “control” has to be implemented against the individual entities rather than against the queue items.

But, as usual, if you think there is another option.. let me know!