Queues vs Teams And When To Use Them

I am finally working on a project which has forced me to come to grips with Queues. Queues have been with Dynamics CRM (I assume we still call it Dynamics CRM) for quite a while and, jaded by the limitations of the earlier incarnation, I never had a lot to do with them. However, back in CRM 2013, they got a facelift and made more useful.

Most projects I worked on since then have not needed Queues as they would complicate what was, generally, a simple process. Mostly I have used Team ownership to manage things like Case processing, which works really well.

On my current project, the client wants to triage emails before moving them to Cases and using Team ownership does not quite cut it.

How To Use Teams Like a Queue

Let us start with the simple model: Teams. Records in CRM can be owned by Users or Teams. So, how I often set up Case management is to have a Dashboard with two lists in it:

• Cases owned by my Team
• Cases owned by me

The user then takes a Case from the Team list (auto-assigned as part of the creation process or via Routing Rules), assigns it to themselves so it leaves the Team list and goes into their list. Here they process the Case and close it.

If they need to pass it on to another group or another User they simply change the owner and it appears on their dashboards.

Users can be part of multiple Teams and the Team list only shows the Cases in the Teams they are part of.

The rules for the Team list are also crazy-simple these days.

With service management components like Routing playing nicely with Teams, it is a simple and effective solution.

Going to Queues

If you are using incoming email as an enquiry channel, you will need a Queue to bring in the email records from Exchange. Even with Team ownership, with emails being converted to Cases via Automatic Record Creation, you will still need a Queue.

However, beyond this, if you are processing records with Queues, you get capabilities you do not get with Team ownership.

Firstly, a Queue can hold multiple entities in one list. So, if you want to mix emails and Cases in one list, you can. With Team ownership you are limited to standard views which can only show one entity at a time.

Queues also lend themselves to managing entities like emails which are already, in effect, inactive and, therefore do not have a good concept of open or closed, like Cases.

Managing Records in Queues

Rather than manipulate the record, as we do with Team ownership, we manipulate the Queue Item which is an entity linking the record we want to process i.e. the email, to the Queue.

We can Pick (‘assign’ the item to me for processing), Release (‘unpick’ an item and allow someone else to Pick it from the Queue), or Remove it (take it out of the Queue).

Using these functions we can manage an email via Queues as we would a Case through Team ownership and status management.  This is ideal for managing records where ownership and status management are restricted, as with emails, or where we wish to manage a range of entity types in a consistent way.

Conclusions

I still lean towards using Team ownership as my default position to manage record processing because of its simplicity. Teams are easy to manage and clients understand how they work very quickly.

However, sometimes you need something more. In the case of my client wanting to triage emails before converting them to Cases, Queues was the way to go.

In fact, on this particular project, by the nature of how it has evolved, we are using both techniques. Firstly, emails are triaged using the Service-Queue lists. Once the significant emails are identified, they are manually converted to Cases by the User and assigned to the most appropriate Team. Converting an email to a Case also automatically removes it from the Queue.

Once it is a Case, it appears on the User’s dashboard for allocation and processing using Team ownership. The system works pretty well with, in my biased opinion, the best tools employed when they are needed.

If you are wondering which way to go in managing records, consider the above and see how you go.