As I revised for the MB2-718 exam (Microsoft Dynamics 365 Customer Service) I’m creating blog posts detailing all aspects of my revision. I hope these posts will aid anyone who is also revising for this exam. In this post I will continue to explain the concepts around case management.

The skills measured statement relating to case management is shown below. From this we can see that case management covers a wide variety of capabilities;

In my previous post I covered;

• Cases An Overview
• Case Views
• Searching Cases
• Creating Cases from Activities
• Case Business Process Flow

In this second post I will cover;

• Resolving Cases
• Routing Cases
• Parent / Child Cases
• Merge Cases

As already mentioned cases are a fundamental part of the service functionality in Dynamics 365, therefore I suggest you spend a significant amount of you exam preparation time creating cases and then experimenting on the various ways to route, resolve, cancel merge etc etc.

Resolving Cases

The purpose of a case is to track customer issues, questions, and requests and to manage them through to resolution. It is therefore a given that cases will eventually be resolved and makes it important to understand the resolution process. When cases are resolved we must enter the resolution type, resolution and billable time. Out of the box the two resolution types are “Problem Solved” and “Information Provided.”. The resolution field is simply a text field describing how the case was resolved.

After resolving a case its status changes to resolved. Additionally a resolution activity is created that we can see in the social pane.

Cases are never resolved with open activities. I guess technically this means they can’t be resolved until all activities are completed. However if you try to resolve a case with open activities, you will see a prompt similar to the one below. If you click confirm all open activities will be marked as cancelled. This is because it is not possible to resolve a case with open activities.

It is however possible to create an activity on a resolved case, that way we can have open activities on a resolved case! Why? The resolution logic forces us to complete everything before resolving, that makes sense! But imagine you want to call the customer back to check they were happy with the service provided. Then you would need to create an activity on the resolved case.

Cases can be cancelled or deleted. Deleting a case will also remove all of the associated activities, notes and attachments. Cases cannot be cancelled whilst open activities exist. (So any open activities will be marked as cancelled when you opt to cancel the case.)

Cancelled or resolved cases can be reactivated. (Obviously deleted ones can’t!) You should probably be aware that a resolution activity is created each time a case is resolved. Meaning we can see multiple activities for case resolution. (An example is shown below.) . If the case be reopened the status on the existing resolution activity will change to cancelled. Another resolution activity will be created when the case is finally resolved. Meaning you can have multiple resolution activities per case but only one will have a status of complete.

When the resolve case ribbon button is selected (or the case marked as resolved in the business process flow) the resolve case dialog is triggered. The billable time and total time on the case is defaulted to a sum of the duration of the completed activities associated with the case. The billable time can be changed as you may need to bill more or less time that amount calculated from the activities. This sum of billable time is always all completed activities. (Meaning if you spent 5 hours working on a case, resolved it, reactivated it, spent 5 more hours and then resolved again. You would have two resolution activities, the first for 5 hours. And the second for 10 hours.)

As cases are resolved they will disappear from the active case views, as they are no longer active. They can however still be viewed in the resolved case views.

Case Routing Rules

An important aspect of working with cases is ensuring the right people are working on the right cases. For this we use case routine rules. Cases can be routed to a team, user or queue. This will happen when a case is created or the “Save and Route” command button is selected.

You might want to send all high priority cases to a particular queue or assign all major complaints to your complaints manager. Or, like in my silly example, assign all cases about cats to my cat Jasper!

Whenever the “Save & Route” option is selected you will be prompted that the case is going to be automatically routed. The routing rules are then reviewed and the case assigned to a team, user or queue as required. If not matching rule is found the cased would be saved and the ownership would remain unchanged.

Case routine rule sets are created in the settings / service management of Dynamics 365.

Below you can see my “sensible” example to assign cases to my cat! Notice that in my quick example I have created just one rule item. You could have several rule items in each rule set. (Hence it being a rule set!) Imagine I also had a dog then I could have a rule item to route cases for either dogs or cats. As you’d expect I would!!

Note:
After you create a rule set it will be in draft mode. You need to select activate to make it live. Only one rule set can be active at any point in time. So activating one rule set will set all others back to a draft status.

Opening the detail of my rule item shows that I can filter cases using rule criteria. These simply define which user, team or queue to set on the case and in what circumstance. So in my example all cases with the word “cat” in the title will be assigned to Jasper.

A few summary points on case routine rules;

• Case routing rules can be manually applied from a view or directly from the case form
• Routing rules can be applied to one case or multiple cases at the same time
• Case routing rules actually create a workflow.  You can see this in the system jobs located under the settings
• Organizations can only have one active routing rule set at any given point in time.  If you create a second one and activate that, the first rule set will return to a draft status
• When creating routing rules, you can set conditions.  The “if” conditions are then evaluated against the case(s) to be routed
• When an “if” condition is true one of the two actions can happen. Cases can be routed to a queue or a case can be assigned to a specific user or team

Parent / Child Cases

Parent and child cases are designed to help cases be used efficiently. You can create a primary case (parent) and then create a secondary case(s) (children).  Child cases can inherit information from a parent case.

You can see child cases in the case relationships section of the case relationships tab. (As shown below) To create a child case you use the “Create Child case” button which can be found in the command bar.

Note:
You might need to be aware that a child case cannot be a parent. Meaning a complex hierarchy of cases is not possible.

Tip: On a child case you can see a parent case field in the additional; details tab. This will allow you to quickly navigate to the parent from the child.

It is also possible to build a parent / child relationship between existing cases. Below you can see that I have selected three cases. I can then use the “Associated Child Cases” option to link these.

Below you can see the dialog that will display have clicked the associate child cases option. Here I can select which case should be the parent. Then the others will be linked as children.

You can also specify what happens when the parent case is resolved.  Including;

• Preventing the parent from being resolved until all the children are resolved
• Resolving all of the children automatically when the parent is resolved
• Do nothing

Within the service management options under setting, you will find settings that govern how the relationship between parent and child cases behaves;

Notice that you can control quick attributes will map from the parent to child case as cases are created. Additionally you can specify what will happen when the parent case is resolved. Including only allowing the parent to ve closed if all children are resolved. Plus automatically closing all child cases when the parent is closed.

Tip: The default out of the box setting for the “specify closure preference” option is unchecked. Meaning the resolution of parent and child cases is completely unrelated.

Merge Cases

Sometimes you might find that duplicate cases have been created, maybe a customer reports the same problem on different communication channels or multiple contacts at an organization report the same issue. When this happens cases can be merged, avoiding the need to resolve each incident separately.

Merging cases combines related open activities and attachments under one case and cancels the other case(s).  When a case is merged, the state of the case is changed to cancelled and the status reason is changed to merged.  You can merge up to 10 cases at a time.

To merge case select up to 10 cases and then select the merge case option.

You are then presented with a list of the cases to merge. In this example I deliberately selected a resolved case. Notice that the resolved case has not been include in my list of cases to merge. As you can only merge open cases.

You can see any cases that have been merged into a case in the case relationships tab.

If you merge a case that has child cases (i.e. A Parent), then the child cases become child cases of the new parent case

You can only merge a child case into another child case if both of the child cases have the same parent case.

Theoretically, you could merge cases from multiple customers. (Although this isn’t common.)

Hopefully this post has helped you prepare for your MB2-718 exam. As always I do stress that you should test out these options for yourself, do not rely on just theory! 