This is the next instalment in my series of posts describing the information needed to pass the MB2-714 (Microsoft Dynamics CRM 2016 Customer Service) exam, this time I will look at cases and case management.
If you are familiar with CRM, you may find much of this post covers concepts that you are familiar with but if you are preparing for the MB2-714 exam a little revision won’t hurt.
The most fundamental entity in the service module of Microsoft Dynamics CRM is the case. (Also know as incident.) In this section of the exam you will need to be able to;
- describe the main components of working with a case
- describe the system fields available on a case
- explain how to create cases from activities
- understand case related business process flows
- know how to resolve cases
- define advance configuration options (e.g. Case routing rules.)
- consider how to manage cases, including merging cases
As cases are the most fundamental entity in service, you are going to need to be aware of all the functionality related to cases in great detail. (Sorry if that fact makes this a long post. L )
Cases represent a single incident of support, some companies may refer to a case as a ticket, service request etc. Each customer can have multiple cases at any moment in time. Cases have subjects, knowledge base articles, products and / or entitlements related to them. Cases also have activities associated with them. And cases can originate from activities, such as an email support query.
Cases can be created from the case form, a quick create form or by converting activities. (Activities can include, appointments, emails, phone calls, faxes, letters, service activities, campaign responses, tasks and even custom activities.) It is also possible to use record creation rules to automate creation of cases, for example on receipt of an email.
Out of the box the customer (account or contact) and case title are the mandatory fields on a case.
Cases, by default, utilise a business process flow to display stage information. The default stages are identity, research and resolve.
Key actions on cases include creating a new case, cancelling a case, resolving a case. Other actions include follow / unfollow, copy / email link, bulk delete, run a report, export to excel, import data, chart, advance find, send direct email (utilising templates), run workflow / dialog and switch process.
From a case you can also save and route cases, create child cases, cancel cases, add to a queues, assign cases and opt to NOT decrement the case entitlement.
Out of the box tabs on the case form include;
- Case relationships (similar cases, merged cases and child cases)
- Additional details, associated knowledge record
- Social details (social profile, influence score etc.)
- Enhanced SLA details
- Contract information
In the centre of the “standard” case form the social pane gives users access to posts, activities, knowledge base articles and notes.
NOTE: Contracts have effectively been replaced by entitlements and are only included for backward compatibility.
Views are lists of data and are used to filter results. Examples include “Active Accounts”, “My Accounts” and “Resolved Cases”. Views can be system views and personal views. Many system views are provided out of the box but others can be added by developers. Personal views are saved advanced finds and can be created by users. Personal views can be shared with other users / teams in the organisation.
Note: Customizers can deactivate system views; this does not remove the view from the system but does hide it from users. Deactivated views can be reactivated.
From any case view the user can select multiple rows in a view. They then have the ability to perform actions on all the selected rows including delete, bulk edit, merge cases, apply routine rules, assign, add to a queue. If just one case is selected it is possible to resolve or cancel the case directly from the view. (You can NOT resolve or cancel when multiple cases are selected.)
Views can be sorted by clicking on column headings. Plus you can sort by multiple columns by holding down the shift key and selecting additional columns. An arrow will show in the column heading depicting the direction of the sort, clicking the column again will change the direction of the sort.
The view can be refreshed by clicking on the refresh icon on the upper right-hand corner of the view. This is more efficient than clicking “F5”, as the icon refreshes just the view not the whole CRM page. Clicking the refresh icon effectively just re-runs the query.
The filter icon can also be used to filter the contents of a view. (This operates a bit like filtering columns in Excel!)
Cases are commonly searched directly from views by selecting a specific view or using the filter functionality. It is also possible to search for specific cases by typing directly into the quick find search box, by simply entering what is required or by also entering wild cards. Typically, the direct search will use case number or case tittle to locate the case however customizers have the ability to extend this functionality to decide exactly which fields will be included in the search.
Convert Cases from Activities
Activities track relevant interactions between a company and their suppliers / customers. There are many situations when you might want to convert an activity into a case, for example a customer may email about an issue with a product. The email can then be converted into a case. If the CRM Outlook client is being used the process for converting an email to a case can be done directly from Outlook. (if the email is first tracked in CRM.) Alternatively, an email can be converted to a case in the web client.
When converting an activity into a case, you confirm the customer and case subject. You can also select to automatically open the newly created case and optionally close the activity that is the source of the case.
When an activity is converted into a case the originating activity is automatically tracked against the newly created case.
Business Process Flows
I mentioned business process flows a little earlier in this post, these are a key element of working with cases. Typically, organizations have specific stages in their service management processes. Business process flows can help guide users through the steps to complete each stage. On a CRM record, each stage of the process is represented by a different chevron. Additionally, within each stage multiple steps can be found that the user needs to take before they move on to the next stage. Some of these steps may be mandatory and need to be completed before the user can navigate to the next stage. (For example: in the identify stage you must enter the customer before moving to the research stage.)
Business processes help to provide a consistent approach to handling cases. They can also contain conditional branches giving the ability to handle multiple scenarios.
You can move forward and backwards in the business process. The active stage is indicated by the position of the flag icon in the process bar.
An out of the box process for management of cases is provided but it can be customized to meet an individual organisation’s needs.
Note that cases aren’t the only record type that can leverage business process flows, they can be applied nearly any record type in CRM. It is quite common, for example, to have a business process flow to manage the sales cycle.
Business processes can be tied to security roles, meaning not all processes will be available to all users.
Clicking mark resolved in the final resolve stage is going to trigger the resolution process.
The purpose of a case is to track customer issues, questions, and requests and to manage them through to resolution. It is therefore important to understand the resolution process, it is a “given” that each case is designed to move through the entire resolution process. Cases cannot be resolved until all activities on the case have also been resolved.
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.
Cancelled or resolved cases can be reactivated. (Obviously deleted ones can’t!)
Cases can be assigned to users or queues.
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 activities associated with the case. The billable time can be changed as y0u may need to bill more or less time that amount calculated from the activities.
Once a case is resolved its status changes to resolved and becomes read-only. Whenever a case is resolved a resolution activity is automatically created and associated to the case. If the case be reopened the status on the 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.
If you try to resolve a case with open activities, you will see a prompt similar to the one below. If you click confirm the open activities will be marked as cancelled. This is because it is not possible to resolve a case with open activities.
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.
- 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 at any given point in time. If you create a second one and activate that, the first one will deactivate
- 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 also specify what happens when the parent case is resolve. 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 can set what attributes are mapped between parent / child cases and what happens when cases are resolved.
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 organisation 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.
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 understand the details you’ll need to understand around cases for the MB2-714 exam. J
Next time I will look at the knowledge base and how this can be configured to help with customer service.