Dynamics CRM’s Service module, and specifically the Case record, is a great option for managing requests from customers or clients. The Case allows you to easily track and organize all the incoming and outgoing correspondence for a specific request, as well as set and track metrics around requests and responses.
Dynamics CRM also allows you to manage these Cases in Queues, to help with routing and workload balancing, which can add further benefits. However, these benefits do come with some tradeoffs in terms of additional management and maintenance.
So, what is the best course: Should you queue, or not queue?
Let’s have a look at some of the pros and cons.
What you get with Cases only
Whether or not you use Queues, you still get benefits from Cases:
- Cases have an Owner, for security and work management.In CRM 2011 this owner can be a User, or a Team
- If you choose team ownership, this can be used as the basis for managing security, so that only team members can see and/or edit Cases owned by their team.
- Ownership can also be used as a way to assign cases to be worked on. You may choose to assign cases to a User, or to a Team.
- Cases organize and package all your related activities. Once an incoming email is associated with a case, all incoming and outgoing emails in the subsequent thread will be associated with the case automatically – a neat organizing trick. (Note that for emails you can set up CRM’s email router, and direct emails sent to one or more Exchange inboxes into CRM.)
- Cases help you understand the status of requests. You can resolve, reactivate, or cancel cases, so you always know the state of the work.
Adding on Queues
Queues give you some additional features, which really come into play when you are managing a large set of requests in the Queue grid view:
- Work on and Release actions, to indicate who is currently working on an item in a queue.
- Route and Remove to move items between or out of work queues.
- You can also add other work types, notably e-mail and other activities, to the same Queue.
- The Queue grid also has a built-in dropdown that allows you to quickly filter by a specific queue, which is handy.
The Queue ribbon, showing actions that you can take on Queue Items (for Cases and other records):
Note the fundamental structural concept for Queues in CRM 2011: When you add a case to a Queue, CRM creates a Queue Item record for the case, which includes the Queue field (managed via the “Route,” “Remove,” and “Add to Queue” actions) and the Worked by field (managed via the “Work on” and “Release” actions). If a case is removed from the queue or resolved, the Queue Item is deleted. If you remove an item from a queue, the Worked by value (which resides on the Queue Item) will be cleared with the deletion of the Queue Item, but if you move the case to another queue, the Worked by value will remain.
Example of a Queue Item record, showing the Queue and Worked by fields:
Now, you have quite a few organizing principles around the ownership of one record:
- Owner (user or team) – on the Case
- Worked By (user or team) – on the Queue Item
- Queue (user or team) – on the Queue Item
Given all these options, it’s best to make some considered design and direction choices up front, using complexity where you need it, but avoiding it where you don’t.
Design and Approach Options
Here are some possible scenarios for consideration:
- Users have their own personal queues and manage multiple work types independently (not always bundled in a case). Work may originate in one or a few general unassigned queues, and then various users or an appointed triage user can add multiple types of work (letters, emails, cases, etc.) to users’ personal queues. Read/edit security for the user queues should be simple – either organization-wide, or based around just a few large teams. The “worked by” (who is working the case) value likely is not needed here as it duplicates the personal queues. This approach may work well for slow-moving work, or work that does not trade queues multiple times before resolution, or small teams.
- Queues are not used – instead use Team and User Ownership assignment for Case management (simple security/smaller orgs only). In this scenario, you could potentially use team and user assignment only, where team assignment essentially means “unassigned” for that group, and user ownership indicates who is working on a case. Read/edit security should be simple – either organization-wide, or based around just a few large teams. System views and filters could be all you need for a fairly simple set of teams and users.
- Queues are not used – replace with Team Ownership assignment for Case management. This could be a clean and robust design option when tighter read/edit security is required. All cases and their related activities are owned by a team – never a user. When adding security per team, make sure that activities have cascading permissions so that they are governed by the permissions on their parent case, so you keep the same security and management model for the child activities. If you want to track who is working the case within the team, you could opt to add a custom field to the case record.
- Teams have their own Queues (larger/more complex organizations with higher volume). This requires some additional maintenance and planning because you are now managing another entity (Queue Item) and a larger number of separate settings (Owner on Case and Activities, Queue on Queue Item, Worked by on Queue Item). As with option 3, make sure you can cascade the team ownership down to the child activities. Consider this option if you have a lot of queues (teams), and people who are members of multiple teams. This option provides the flexibility to manage multiple work types in the same place (including incoming emails that arrive after a case has been resolved). The Queue dropdown on the Queues grid can be very helpful here, because you can then have multiple system views and filter them very quickly by a specific queue out of a long list (sounds simple, but it can provide good usability because of the added efficiency).
If you pursue the last (most complex) option, there are further customizations you will want to consider to keep the team and queue values in step.
More Quick Notes around Queues
- Outlook Client Views: If you are using the Outlook client, you automatically get all the CRM 2011 Outlook client view goodness for the Cases grid (including tabbed views, preview pane, grouping, filters). However, the Queues grid does not include the preview pane or other Outlook enhancements.
- Caution for Queue Items plus Case child records – added complexity: If you have created a custom entity below the Case (for example, a tracking record to manage response time or other metrics) and you are also using queues, you will now be managing 3 records (Case, the custom child record, and Queue Item). If you want to track and update a value such as Queue or Worked by on all 3 records for visibility, you will want to be very careful with your code logic to avoid an infinite loop that continuously updates each record.
- Routing and escalation: There is a great deal of useful automation that is possible here via workflows and other methods – escalations and routing based on time, priority, customer or account name etc. A good CRM design will allow for this whether or not you use queues to manage your cases.
- Incoming Email and Queues: What if you decide you don’t want to use Queues, but you are managing inbound email? You will still need to use Queues in this scenario, but you could essentially employ one or more Queues in the background before users manage the emails, and then use rules/workflows to auto-create cases, remove items from the Queue, and assign them out to teams as needed. This would remove Queues from end-user-facing work management features, while still allowing the email to flow through.