Поделиться через

CRM 2013 Services Module - Case Enhancements

  • Статья

The service module in Microsoft Dynamics CRM has undergone a lot of changes in the recent times, keeping in sync with its ‘Care Everywhere’ concept. It offers multi-channel support and enhanced core features. The objective of this post is to bring more clarity into the Service Module functionality within Dynamics CRM 2013’s Leo release.

The feature enhancements are mainly in the following areas:

  • Case Management
  • Entitlements & SLAs
  • Queues & Automatic Case Routing
  • Unified Service Desk and Parature

This blog will primarily focus on the ‘Case Management’ area. I will include the other features in the upcoming blogs.

1. All the workflows that used to manually create to route emails to specific queues in the previous versions of CRM have become available as Routing Rule Sets and Routing Rules. The important points to note in this context are as follows:

  • The Routing Rule set is an umbrella that can hold multiple routing rule items

  • The routing rule items within a ‘routing rule set’ will determine the actual routing flows. The order of the routing rules matters, as the routing process starts checking the conditions from the first rule to the last. So always start from a specific rule to a generic rule. If you put the generic rule as the first rule, every case would satisfy that condition and will get routed to the Queue specified in that rule. This could lead to serious consequences.

  • Only one routing rule set could be active at any point. So it would apply to all the cases created. Activating a second one will leave the first one inactive

  • All case routings are managed through background workflows

The following would serve as an example:

Routing Rule Set: Routing Rule Set - India

Routing Rule Items within the Routing Rule Set:

    • Rule for Critical cases (High Priority cases
    • Rule for the other cases (Normal Priority)

 

Routing could be done based on many criteria. One solution which is easy to implement would be based on the ‘Subject’ field in the Case entity. The ‘Subject’ field helps in classifying the support tickets. The best thing is that multiple levels of classification is possible using the Subject field. In real-life scenarios, this would translate into something like:

If the case is related to Software-Break-fix support, send to one particular queue. If it’s related to Software-Migration support, send to another team. Or if it is Hardware-Product support related, send to the hardware team. The Subject field (To edit the values in the Subject field, go to Settings -> Service Management -> Subject) would look something like this:

This helps you to clearly categorize the service tickets and assign to queues accordingly. And depending upon the value of the Subject field, the cases could be automatically routed. You could also route cases based on other case related fields like Priority, Status etc.

Creating Routing Rule Set and routing rule items within it is fairly simple. Click on the Settings -> Service Management -> Routing Rule Sets, the pop-up will help you specify the condition and select the queue to which the case should be routed.

A Routing Rule set has to be active for it to start working. An active routing rule set automatically applies to all automatically-created cases. To manually apply the rule to existing or manually-created cases, in the list of cases, select the cases that you want to route using this rule, and on the command bar, choose Apply Routing Rule.

If you click on the ‘Background Processes’ tab in the open case record right after a case gets created (Click on the bottom arrow next to the case and select Background Process), you might be able to see something like this:

 

The succeeded processes are removed, so the ‘Routing Rule’ entry wouldn’t be available after some time. Once the routing rule succeeds, click on the ‘Queue Item Details’ button on the Case entity screen (the ribbon at the top) to confirm the queue. The pop-up as shown below will give you the details.

 

Alternatively, you could also open the Queue record and check if the case got assigned to it.

2. Some pointers while associating and merging Multiple cases

  • Select multiple cases and associate/merge them. You could also open a case record and add child/associated cases within it (there are separate sections for Merged Cases and Child Cases within the Case record)

  • In Parent-Child hierarchies, only one level is possible, which means that child cases cannot have child cases within them

  • Only a maximum of 100 child cases are allowed for a parent case

  • You could merge up to 10 cases – The case that is selected as the main case will retain its content and the rest of the cases would be added as the merged cases

  • Once the cases are merged, the operation cannot be undone

  • All the merged cases are marked cancelled and only the primary case will remain active. All the activities, notes and attachments of the cancelled cases would be re-parented to the primary case. No option to choose individual fields from the cancelled cases, but the cancelled cases would still be available in the ‘Merged Cases’ section in the primary case

  • The Parent and Child Case settings could be changed from the Settings -> Service Management area