Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
I am currently revising for the MB-230 exam. This exam is for Microsoft Dynamics 365 and covers all aspects of customer service. As I revise I plan to publish blog posts that collectively will become a complete revision guide for anyone embarking on the same journey as me. In this post I will begin to discuss the options available to use for case automation.
Part of the skills measured statement relating to case management and case automation is shown below. From this we can see that case automation includes many topics. Including record creation rules, case routing, status reason transitions and more.
In this post I will cover;
In a future post I will cover;
I will leave “Customer Voice” for a further post as that “feels” like a bigger subject that deserves its own post.
As agents work on cases it can be useful to view similar cases, as these might give clues to resolution approaches. Or maybe it might highlight a fact that other people are having a similar issue. Advanced similarity rules give us a way to configure how this feature will look for possible similar cases.
Below you can see that I have opened a case and that I have navigated to the similar cases area. Having done this I can see other similar cases.
If the agent thinks the information on any of these case may be useful …. Click the case will open additional details without them needing to navigate away from the current case. As shown below!
As mentioned in my introduction to this section we can tailor the similarity rules. Maybe in your organization we only want to look at resolved cases or maybe you’d like to add the ability to search additional custom description fields. Below you can see that I have opened the “Service Management” area of my customer service hub. Here we will find an option called “Advanced Similarity Rules”.
You will see the rules in this option. Notice that my rule is active. If you wish to amend the rule you will need to deactivate it. And don’t forget to re-activate … as until you do the search will not operate!
Opening my rule will initially who various options. I can for example add “noise key phrases”, these are terms I wish to exclude from my search. Maybe you have commonly used business phrases that would add no value in being searched and could also result in false matches. Additionally I can filter by the case status. Meaning I could focus on just resolved or open cases if required. (Or maybe I want to exclude all cancelled cases from my search!)
The match fields tab lists the fields which are being used in my similarity search. In my example we are just looking in the case title and description.
We can option to complete a text match on the fields, meaning we’d look for matching “phrases” within this fields. Alternatively you could also set the criteria to look for an exact match.
Note: You may need to be aware that the case similarity logic uses the relevance search. Which should ideally be enabled to allow accurate matches to be returned. Additionally any fields enabled for exact matching logic will need to be defined as “find columns” in your quick find view on the case entity.
You will find a detailed explanation of the implications of the relevance search and how to add columns into your quick find view in the article below from docs.microsoft.com
Suggest similar cases for a case with Dynamics 365 Customer Service | Microsoft Docs
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 routing 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. I think the idea being that you’d initially route a case to a queue when it is created. But during the life of the case we can use the “Save & Route” option to trigger the case to be re-routed to an alternative queue. (You might do this, for example, when the priority changes.)
You might want to send all high priority cases to a particular queue or assign all major complaints to your complaints manager.
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 routing rule sets are created in the settings / service management of Dynamics 365. To find this open the customer service hub and change to the “Service Management” area.
The concept is that we create a set of rules for a table (entity). You might find it useful to understand that we can create routing rule sets for any entity that can be queued. For example, above I have created a routing rule set that might apply to leads collected from our web site.
Organizations can only have one active routing rule set [er entity 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
Below you can see an example rule set. Notice that I have two rule items (you could have more) … in my example I have deiced to route high priority cases to a particular queue. I also route any cases that have been generated from Internet of Things (Iot) alerts to a particular user.
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.
Notice that my rule set below is “Read-only” meaning it is activated. If I need to make any changes I will need to deactivate it, make the changes and then re-activate.
Opening the detail of my rule item shows that I can filter cases using rule criteria. This is used to decide when a particular routing rule should apply. In my simple example I am used checking the priority of the case but you may need to create more complex rule criteria.
Below the rule criteria I define what action I want to take. In my example I have decided to route to a queue called “Urgent Cases”. But I could have easily routed to a team or user.
We have seen that I can route cases when they are created or when I select the “save & route” option. It is also possible to select one or more cases from a view and use the “Apply routing rule”. This might be really useful if you need to re-evaluate the queue for many cases at once.
Record Creation Rules
Record creation rules are something I often think about in context of customer service scenarios but you could also use them in many other scenarios. For example in service I might want to create a case when someone sends an emails to my “email@example.com” email address. But equally I might want to create a lead if someone sends an email to “firstname.lastname@example.org”.
Tip: If you haven’t used record creation rules for a while ensure your revision includes creating some rules! As they have evolved in recent times. In that they are now based on Power Automate Flow rather than classic workflows.
You can find the option to setup automatic record creation rules in the service management area of the customer service hub. I have shown mine below.
You might find this article from Microsoft useful!
Automatically create or update records in Customer Service Hub (Dynamics 365 Customer Service) | Microsoft Docs
Initially we create the record creation rule “header”, this includes setting the source type, queue and such like. Below you can see I have linked my record creation rule to a queue I’ve called email@example.com.
The queue field allows me to define the source queue. Often this could be a queue associated with a “generic” email account. For example, firstname.lastname@example.org. Meaning any customer who sends a message to this type of address may be registering a service request or sales enquiry. Prior to creating the record creation rule you may need to create and test a suitable mailbox.
Activity type to monitor, a common use of automatic record creation rules is to create records as emails arrive. But we can configure multiple other source types. Including phone calls, social activities and many more.
Additionally you may need to check (or change) the options on the advanced tab. Here you can control when happens when an email from an unknown send is received. In some scenarios you may want to ignore emails from unknown sends. But in others you may want to automatically create contact record for these people.
Plus we can require a valid case entitlement. In the scenario we would want to identify the sender and also check they are entitled to support on the email channel. (or other channels as required!)
The final option lets us define what will happen is an email is received regarding a resolved case. We might want to track those emails against the resolved case. But it may sometimes be an advantage to create a new case if an email regarding a resolved case is receive ed. (As this might suggest a new problem.) This logic can be tailored, as maybe you don’t want to create a new case if a reply is received quickly. But after a period of time it might suggest the customer still has an issue and a fresh case might be required.
Having specified the “header” details I can then add the record creation and update rule. In my example I will create just one rule but you could have multiple rules with different conditions active on one mailbox.
Below you can see that we give the rule a name and then specify a condition to define when this rule should be triggered. In my example I decided to add some conditions to try to filter out automatic replies (e.g. out of office messages) and email that don’t allow replies.
Having defined my condition I now say which type of entity I need to create.
In background a Power Automate Flow will be generated for me! I can click on the “Save and open Power Automate” option to review this. Mine is shown below. In is important that you notice that some of the actions in this flow tell you not to rename the action. So don’t! The actions will be pre-populated and may be sufficient to create your case. But equally you may need to amend these. (For example, you may have some custom fields on the case you need to default etc.) You may also want to add some additional actions into this Power Automate Flow. Maybe you’d want to send an acknowledgement to the customer or a notification to an agent.
As part of your revision I suggest you experiment with make changes to this Flow and maybe add some actions to help you understand how this process works.
I have actually covered quite a lot of theory in this post! Similarity rules, case routing rules and record creation rules are important but potentially complex concepts, therefore I suggest your MB 230 revision includes plenty of hands on time using these features.
Business Applications communities