Neil Parkhurst's Groups Activities

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;

Advanced similarity Rules
Record Creation and Update Rules
Case Routing Rules

In a future post I will cover;

Case resolution form
Status reason transitions
Busines Process flows

Note:
I will leave “Customer Voice” for a further post as that “feels” like a bigger subject that deserves its own post.

Similarity Rules

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

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.

Note:
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.

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.

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 “support@blablabla.com” email address. But equally I might want to create a lead if someone sends an email to “sales@blablabla.com”.

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.

Tip:
You might find this article from Microsoft useful!

Automatically create or update records in Customer Service Hub (Dynamics 365 Customer Service) | Microsoft Docs

Rule Creation

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 info@npdynamics.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, info@npdynamics.com. 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.

Tip:
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.

I have already covered the following topics in a previous post;

Similarity Rules
Record Creation and Update Rules
Case Routing Rules

In this post I will focus on;

Case resolution form
Status reason transitions
Busines Process flows

Note:
I will leave “Customer Voice” for a further post as that “feels” like a bigger subject that deserves its own post.

Case Resolution Forms

The point of a case is to log and resolve a customer query. Therefore the resolution approach is essential to this process. With previous versions of Dynamics 365 we had just one possible approach to case resolution but we can now customize the resolution process. It will therefore be essential that during your revision you are aware of the options to customize the resolution dialog.

Within the customer service hub you will find the service management area. It is here that we find many options that control the settings connected with customer service. In the “Service Configuration Settings” option you will find the ability to change the case resolution dialog from the standard dialog into a customizable dialog or a quick create dialog.

Standard Dialog

The standard case resolution dialog is shown below. This is the standard approach to case resolution that has existed in Dynamics 365 for many versions. And in many situations will work perfectly well without change.

Customizable dialog

Next we have the customizable case resolution dialog. At first glance it will look very similar to the standard dialog!

However as a developer I can use “make.powerapps.com” to customize the resolution form. So if we navigate to the “Case Resolution” entity you will find the “Information” form. As an example I have created a solution and added the information form of the case resolution entity.

Once done I can now use the Power Apps form editor to make makes to the form. Maybe, for example, I don’t need to see the total time and billable time fields. So I could simply hide them on this information. Once the change is completed and published my case resolution form will behave differently.

Quick create dialog

The final option available is to use the quick create dialog from the case resolution entity. And like the customizable dialog mentioned above a developer could tailor the quick create form as required.

Below you can see an example of the quick create dialog. Notice that the user experience is slightly different but until I customize the quick create form the fields is identical.

Tip: This post from Microsoft includes a description of a possible way we might want to customize the resolution process.

Status Reason Transitions

The is idea of customizing status reason transitions is to enforce a logic in what status values can be assigned next. You may, for example, want to ensure a user can change an “on hold” case to be “In progress” but you may want to prevent the user taking an “on hold” case directly to a resolved state.

Before considering status reason transitions you should ensure you understand the concepts of status and status reason.

Status… the status is the “ultimate state” of a record. Typically the values cannot be customized and for most entities just two states exist. (Active and inactive.) Although a case can be “Active”, “Resolved” and “Cancelled”.
Status Reason … the status reason field shows the reason for a particular state. For example, an active case can be “In Progress”, “No Hold”, “Waiting for Details” and “Researching”. You can customize the options in the status reason! (Meaning you can add additional reasons as required.)

Status reason transitions allow us to decide which values are available for transition at each reason. This concept might be of particular use if you have created custom status reason values and want to control their behavior.

Below you can see that I have opened my status reason field on the case. It is here that I have customize the options available. I can also use the “edit Status Reason Transitions” option. Importantly notice I am using the classic interface, you may need to be aware of this! As at the time I am creating this blog post I don’t believe you can edit the transition reasons in the newer interface found in “make.powerapps.com”. But luckily we do have a “switch to classic” option which helps in rare situations like this!

Below you can see that I have clicked on edit status reason transitions and I have enabled the feature. Now, for each status reason I can define which reasons can be selected.

For example, with the settings below I can change a case in status “Waiting for Details” to be “Information Provided”, “Cancelled” or “Merged”. But no other state. Therefore before the case can be resolved I would force the user to show that the information has been provided.

This article from Microsoft might be useful when reviewing status reason transitions …. Define status reason transitions with Power Apps – Power Apps | Microsoft Docs

Business Process Flows

Business process flows 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 Dynamics 365 record, each stage of the process is represented by a circle. 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.)

You can see which is the current stage as it has the “double circle” icon. Usefully we can see how long this case has been paused at this stage. Completed stages are marked with a tick.

Clicking on a “stage circle” shows the steps (or fields) which need to be completed before progressing to the next stage in the business process.

The out of the box business process flow on cases includes the following stages / steps;

Stage	Steps
Identify	Find customer (Mandatory) Find Contact
Research	Assign to Others (Mandatory)
Resolve	Mark as resolved

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 “double circle” icon in the process bar. And how long the entire process has been active. In my example above the research stage has been active for just 1 minute, as I have only just move the process forward to that stage.

An out of the box process for management of cases is provided but it can be customized to meet an individual organization’s needs. In fact I would suggest that this process will almost always need to be customized to meet the specific needs of each organization.

Note:
Cases aren’t the only record type that can leverage business process flows, they can be applied nearly any record type in Dynamics 365. It is quite common, for example, to have a business process flow to manage the lead to opportunity cycle.

In the case resolution stage we can use the finish button on the business process flow to stop the timers in the business process flow. Therefore, after actually resolving the case you may want to also use the finish button to halt the business process flow.

Tip:
If you do finish the business process flow and the case is reactivated, you may need to also reactivate the business process flow. If, for example, you need to move the stage back to “Research” now the case is re-opened. You do this from the Process option on the case. (As shown below.)

I suggest that part of your revision should include “playing” with the put of the box business process flow. Try moving cases from stage to stage to understand how this operates in detail. And experiment with finishing and reactivating processes.

You may also want to attempt to customize the business process flow. Below you can see that we have a design screen available at make.powerapps.com. This gives developers that ability to tailor business process flows..

If you wish to find out more about amending business process flows …. you could refer to this post for more information on business process flows.

In this post I have (again) covered loads of detail! This time around case resolution, status reason transitions and business process flows. Your MB 230 revision should include some significant hands on time experimenting with these features. Enjoy!

Out of the box it is pretty easy to create a two stage SLA with Dynamics 365. This is great as often we have a need for a service level agreement that relates to “First Response By” and “Resolve By”. But occasionally a requirement comes up for a third stage to our SLA, typically something like “Resolution Planned By”. I recently needed to configure exactly this for a customer and thought it might be useful to document the process.

In my example I am going to concentrate on the case table, as generally speaking SLAs will be applied to cases. But you should be aware that you can associate service level agreements with other tables. Maybe you have an SLA for work orders, leads or pretty much any Dynamics 365 entity.

The steps involved in creating the third stage are as follows;

Step One – Create a two stage SLA!
Step Two – Create a lookup to “SLA KPI Instance”
Step Three – Create a “Resolution planned” column
Step Four – Create a quick view form and add to case form
Step Five – Create third stage in SLA KPI
Step Six – Create SLA

Step One – Create a two stage SLA!

For the purpose of this post I am going to assume you already have a two stage SLA. This does mean I’m making another assumption that the reader already has at least a basic understanding of how service level agreements in Dynamics 365 operate.

Below you can see that I have created a very simple example SLA. I have just two SLA items, one for first response and one for resolve by. So a simple but typical SLA.

Below you can see that my SLA results in the standard set of two timers on my case record.

Step Two – Create a lookup to “SLA KPI Instance”

My two timers are fine! But in this example I want to add a third SLA, maybe I want to have an SLA to show when a resolution must be planned by.

Below you can see that I have created a solution for my example. Just to keep my changes grouped together! The first thing I need to do a create a new lookup field to the “SLA KPI Instance” entity. Below you can see that out of the box we already have two fields one for first response and one for resolve by.

Below you can see that I have created a new lookup field. I have mirrored the out of the box naming convention by calling my new field “Resolution Planned By”.

Step Three – Create a “Resolution planned” column

Next I want to create a simple yes/no column the purpose for this will become clearer soon!

I’m going to just call my field “Resolution planned”! Notice that I have opted for a “Yes/No” field with a default of “No”.

The purpose of this field is so that I know when a resolution has been planned. With my first response SLA I have an out of the box field called “First Response Sent” which can be used to know when this SLA has succeeded. So I am creating this field to simple mirror that idea.

In a real-world solution you could decide to know your SLA has succeeded using a different method. You will also probably want to add this field into your business process flow on the case table. But I am simply going to add it to my case form for my demonstration. My case form is shown below ….

Step Four – Create a quick view form and add to case form

I next want to create a new quick view form in the “SLA KPI Instance”. The reason being that the timers I see on the case form for first response and resolve by are actually quick view forms we can find on the “SLA KPI Instance” table.

Below you can see that out of the box I have two quick view forms that relate to cases!

I simply open one of these forms. I then change the field name on the form and save it with a new name. Say “Resolution Planned SLA”.

Tip: I think you should be able to complete this step in the newer editing experience we have in make.powerapps.com. But on the day I tried it I seemed to be struggling! So I reverted to the classic interface!

All I did was rename the existing timer control to be called “Resolution Planned In”!

My final step was to add my newly created quick view form into my existing case form. When I added the quick view form I selected the lookup we created earlier and then the quick view form we have just created.

Below you can see that I have positioned my new quick view form between the two existing out of the box forms.

Before you continue to the next step …. Don’t forget to publish all your changes!

Step Five – Create third stage in SLA KPI

Now my customizations have been completed I can create my the SLA.

Firstly I want to define a new SLA KPI. I do this in the service management area of the customer service hub.

Having selected the case “entity” I can now also select the “Resolution Planned By KPI” lookup as my KPI field.

Tip: Don’t forget to activate your new KPI after saving it!

Step Six – Create SLA

I can now create whatever SLAs I need using this new KPI. Below you can see that I have created a new SLA item in my demo SLA.

Notice that the KPI I have selected is my new “Resolution Planned By” KPI. Also that my success criteria is using the field I added onto my case earlier. As I am using this to know a resolution has been planned and therefore the SLA has been achieved.

My final SLA looked like this …. Notice that I have three SLA items. When I started I had two!

Now when I create new cases (as shown below) I have three stages in my SLA. “First response in”, “Resolution Planned in” and “Resolve in”. All three timers are independent.

You can see below by setting my “Resolution planned” field to yes my SLA for resolution planning changes to a “succeeded” status.

Hopefully you will agree the process of adding a third stage to the out of the box SLAs is pretty straight forward. You can of course have even more stages if needed! Enjoy.

The section of the skills measured statement that mentions knowledge management is shown below. As you can see we have quite a few concepts to cover connected with knowledge management. I will do my best to cover all of these in this post but please don’t forget that you should actually try these things out for yourself. Real hands on experience is very important!

A knowledge base is a collection of articles which is searchable and can be used to answer customer questions. The articles typically refer to products and services. In Microsoft Dynamics 365 you can search knowledge base articles and quickly associated them with cases, helping to resolve cases. Additionally those articles maybe emailed to customers or even accessed publicly from your customer service portal.

Search Knowledge Articles

Searching for knowledge articles may use the relevance search, so you might need to confirm this is enabled!

You can search for knowledge articles directly from the case form in the customer service hub. As shown below.

Tip: I suggest as part of your revision you experiment with the options available whilst searching!

Articles are initially searched based on the case title. But an agent could refine this search is if needed. The results are sorted by their relevance. The agent can change the sort order to be based on number of views or when the article was last modified. They can also filter articles by status, visibility and modified date.

Articles can be linked to cases. This is useful to show which articles have been used when resolving a case. You can see which articles have been used on the case relationships tab of the case form.

We also have a useful option to email a copy of the article to the customer.

And articles can be rated by agents. This might be useful later when we want to consider which articles are useful as they are and which need to be revised.

In addition to searching for articles directly from the case the agent can use the relevance search to find articles. In the screen shot below you can see that my search has returned both articles and cases which match with the keyword I entered into the relevance search.

You may find this article from Microsoft useful, as it describes the knowledge search ….

Search knowledge articles in the Customer Service Hub in Dynamics 365 Customer Service | Microsoft Docs

Maintaining Articles

We maintain knowledge articles in the customer service hub. You can see below that when I access knowledge articles I can add new ones using the “+ New” option or directly from the + icon in the ribbon bar. (aka Quick create)

Below you can see that I have started to create an article. Notice that a business process flow is used to help with the authoring process.

Tip: Using the business process flow will help you understand the flow of status values on knowledge articles. As they start off as proposed, become approved and eventually get published.

You can use the “summary” tab to view other details about the article. Including its version. Each article has a major and minor version. I will explain these in greater detail below.

It will be import to understand the life cycle of an article. Articles start off in a draft mode. When we move them forward in the business process flow they can be approved or rejected. Draft articles can use the status reason field to show if they are “proposed”, “draft”, “needs review” or “in review”.

Rejected articles will revert to the draft status. Additionally you will see an entry is added to the articles time line containing the reason for rejection.

Approved articles can be published. Below you can see that published articles can be given an expiry date. (Expired articles may still show in search results but will clearly show as expired.)

A published article may have a new version created. (A described below.) Or it can be reverted back to draft mode. Also, an option does exist to directly update the published article if required.

Articles can have major and minor versions. A major or minor version can be created for an existing article. At that point the current published version remains and a copy is created with a new version number. After any changes have been completed the original version will be archived and the new version will replace it.

We can see information in the articles timeline which overtime will provide a useful history of changes in the status and versions on an article. As each time an article is revised a post is created that will help us understand when revisions have been applied.

Additionally the article’s “SUMMARY” tab will give us access to some Additional fields and other related information. Including, related versions, related translations, related categories, related articles, related products.

Article Templates

When you create a new article you can create it as a blank article or use a template. Using templates might be a great way to ensure your articles have a consistent layout!

Below you can see that within the Service Management area of the customer service hub I can use the article templates option to create a template.

I can now use the “+ New from Template” option when creating a new article. As I do this a dialog will open and I can select a template.

Cases to knowledge articles

Sometimes it might be useful to create a new article based on an existing case. Doing so will create a draft article that contains key details from the case. If you do this from a resolved case the content of the article will include the resolution comments from the case.

Below you can see that I have opened a resolved case. The “Convert To” option allows me to create a knowledge article.

Having clicked convert to knowledge article, a dialog appears that will allow me to create anm article.

Below you can see my article has been created in draft mode. It will probably need some edits before being ready to publish but hopefully this process could be useful to at least create the outline of an article that can be revised, approved and published.

Configure entities for knowledge management

We do typically think of knowledge management as being something that applies to cases. (As it does out of the box.) But we can actually enable any entity for knowledge management.

Below you can see that within the “Service Management” area of the customer service hub I have opened the settings option. Within the settings option I can enable additional entities for knowledge management.

The article below from Microsoft explains how to add the knowledge control to the forms of any entity you have enabled for knowledge management.

Add the Knowledge Base Search control to Dynamics 365 Customer Service forms | Microsoft Docs

Categories and subjects

Each article has a subject and can also have categories. The subjects are mandatory and come from the subject tree. You can maintain the subject tree from with the service management area of the customer service hub. Out if the box you will have a default subject tree but this can be customized as required to reflect subjects relevant to your organisation.

You may find this article from Microsoft useful when considering maintaining the subject tree;

Create and manage subject tree (Dynamics 365 Customer Service) | Microsoft Docs

We also have categories that can be added to an article. Like subjects they can be maintained in the service management area of the customer service hub. And like subjects we can define a hierarchy of categories.

Unlike subjects, each article can have multiple categories. Below you can see that I have opened an article and navigated to the summary tab. In this tab, using the related information section I can add multiple categories to each article.

Tip: Categories can prove useful if you are using a customer service portal to show articles to your customers. As they can then be grouped by category.

Hopefully this post has given you a flavour of knowledge base articles and I hope I have covered most of the points significant to passing the MB 230 exam. I strongly suggest you experiment with this feature as part of your preparation. I am confident you will uncover even more cool features by getting some essential hands on experience.

We recorded our recent D365UG Birmingham event. In fact we recorded the one before as well! At these events we had some great presentations. The videos from those presentations are available to watch here ….

The first of four presentations I have uploaded is actually from me! In this video I talk about the customer service workspace and how it compares to other Dynamics 365 apps for customer service.

Next we have a presentation from Ben Warren about The software Bureau’s product to aid data cleaning.

The next presentation is from Benedikt Berghmann, he gives a detailed presentation all about getting started with ALM and Dynamics 365.

And last but by no means least … the final video I’ve uploaded is from Daniel Laskewitz who gives a great presentation all about Power Automate Desktop.

I hope you watch and enjoy all of these videos ….. enjoy.

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 review surveying customer opinions with customer voice.

The section of the skills measured statement that mentions “customer voice” is shown below. Customer voice is a survey tool that we can use for many purposed connected with Dynamics 365, although in our context we are probably going to want to send a survey to a customer after a case is resolved. (etc!)

We use customer voice to capture, analyse and act on customer feedback. The concept being that surveys are created and sent to a customer. Any results collected are stored in the Dataverse and can be reported on alongside other Dynamics 365 data. (Such as cases.)

The customer voice surveys can contain various question types. Including choice, date, ranking, rating and text Additionally we can capture a Net promoter score (NPS) which is a value used to analyse the loyalty of customers. Many organisations focus on the NPS score as it suggests how likely a customer is to recommend them to a friend or colleague. (A good measure of overall satisfaction.)

Tip: Do not confuse “Customer Voice” with “Voice of the Customer” as that was a previous Microsoft survey tool which whilst conceptually similar to “Customer Voice” was quiet different. “Customer Voice” is a rebranded / enhanced version of Forms Pro which is now available as part of your Dynamics 365 subscription.

Opening Customer Voice

Lets start with a simple task … loading Customer Voice!

From my customer service hub (or other Dynamics 365 app) I can use the “waffle” icon.

At this point, if you have an older install, of Dynamics 365 you may see a “Voice of the Customer” icon. (As I have shown below.) This is not the “icon” you are looking for.

Click “All apps” will present more options. See below that I have now located the “Customer Voice” option. That is the one you want!

Once Customer Voice loads you will be presented with a screen that should look something like the one I have shown below;

Create a Survey

The surveys can be organized into projects. Each project would be a collection of related surveys. Your first step therefore will be to create a project.

Each project can include multiple surveys and will include reports that contain satisfaction (NPS) metrics that cover all t he surveys in the project. (A view of each survey within the project can also be created!)

After clicking “+New Project” I can select a project a template. The templates cover several common sales and service scenarios.

As MB 230 is a customer service exam … as an example I will focus on creating a survey using the “Support” template. But I suggest you experiment with the other templates as well. Maybe creating a survey from a blank start point may be a good exercise to help you appreciate all of the elements of a survey!

Next you will select where you would like to create your survey. This will be the Dynamics 365 (Dataverse) instance that contains your customer service application. This probably isn’t your default location so you may need to use the “see all environments” to locate and select the correct one. Once you have selected the correct environment click “Create”.

A survey is now created for me from the template I selected.

You can now amend the design of your survey and customize its appearance. For the purpose of this post I will not focus on these processes! As I’m simply going to work with the survey created from the template.

Tip: I encourage you to experiment with the design elements to add questions to the survey, And the customization options. Such as adding branding or conditional elements (using branching). As always hands on experience is important!

Send a survey

Once we are happy with the design of our survey we will need to distribute it. For this we have several options. Including;

Using automation (Power Automate) to send our survey.
Email the survey to one or more contacts.
By the customer selecting a link to the survey which might be via code you could embed into a web page, just via a URL or from a QR code.

I suggest you experiment with all of these methods of distributing a survey. I am going to stick with the customer service theme for my example. So I want to distribute a survey when a case is resolved. Meaning I will be use the “Automation” option.

Usefully, when we select the automation option a number of templates are available. One of which is “Send a survey when a case is resolved in Dynamics 365”. This is perfect for my example but again I encourage you to experiment with other templates and also maybe create your own automation from a blank flow.

Creating my Power Automate Flow from the template is simple! Firstly I click “Continue” which will confirm that I am going to connect this Flow to Dynamics 365 and Customer Voice.

Next I will need to select the correct Dynamic’s 365 environment before clicking “Create”.

After a very short pause I will see a message that my flow has been successfully created. At this point I can start disctributing the survey by resolving cases.

What has just happened is a flow has been created for me based on a template. In a real world scenario I will probably want to amend this flow before using it. As maybe I’d need to add some additional personalization or filter the sends to exclude certain customers or something ….

So; if you open make.powerapps.com and navigate to your correct environment. Under the “Flows” option you should now be able to see the flow which has been automatically created.

Below you can see that I have used the edit option to open my flow. I could now tailor any of these actions as required. Hopefully you can see that as cases are resolved a survey is going to be sent to my account or contacts as required.

Complete a Survey

As a test I created and resolved a case.(You should try the same as part of your revision!)

The default survey that I was sent looked like this;

Clicking begin survey in the email will open my survey in a browser

Review Results

In my quick example I have (so far) only created one response. (As I have resolved just one case.) As part of your revision I suggest you resolve multiple cases to generate some meaningful data.

See below how I could see details of each question. (I could also use the respondents option to see who has responded to the survey.)

Below you can also see that I can use the satisfaction metrics option to view those all important satisfaction / sentiment scores.

Other things to experiment with are adding alerts which would warn you of certain things. For example someone giving a very low satisfaction rating.

Dynamics 365

To complete my example / test I thought it was worth while to view my results in Dynamics 365. Below you can see that I have opened my case record. In the timeline I can see two actions. The first is an invite to complete the survey. The second is the response received.

Opening the response received allows me to drill into the survey responses. Here I can see details of the survey completed and all the answers given to the questions. This linking of the survey and the case could be very imp0-ortant. As now when someone gives a good ort bad survey response I can drill into the case to understand the full detail behind the scores given by the customer.

I hope you can see that we could do so much more with the “Customer Voice” option. My example has been a really simply eon designed to give you an overview of the basics. I encourage you to spend some hands on time with Customer Voice as part of your MB 230 revision. Enjoy.

Below you can see an extract from the skills measured statement of the MB-230 exam. Notice that we’ll need to know how to configure queues, add cases to queues, configure tables (entities) for queues and more.

What is a Queue?

Let’s begin with a simple question …. “what is a queue!“.

A queue is simply a list of “work items” including cases, activities or other entity types. Queues are a place to organize and store “jobs” waiting to be processed. Dynamics 365 includes queuing and workflow tools to efficiently manage incoming requests, this post will explain the concepts connected with this management.

From a customer service point of view queues can be a very important concept to allow teams of users to manage incoming requests for service, as they can be routed to suitable queues to ensure the right agents work on the correct pieces of work.

Note: In this post I will not be discussing additional concepts we have within Omnichannel for Customer Service. As with that there is a concept of a messaging queue which is used to route conversations to agents. (I will cover those concepts when I review Omnichannel!)

Queue Types

There are essentially two styles of queue, user queues and system queues.

User queues are tied to an individual user (or team), whilst system queues are available across the whole system. User queues can be used to route important activities to individual users. Each user will have a queue (local user queue) created automatically as their system user record is created. Other users do not have access to see the details of the queue. It is possible to configure Dynamics 365 to automatically move items to local user queues as they are assigned.

System queues are used for queues of work that need to be shared. (For example: A queue of newly arrived support cases.) System queues are a container for work items that a group of people might work on. Queues can be configured for any record type in the system but by default queues are enabled to work with cases and activities.

With system queues agents can indicate what queue items they are working on, providing managers the ability to see who is working on what. (And importantly what items are not being worked on.)

System queues can be given a type of Public or Private. Public meaning that the queue is available to all users in the system. Private indicating that it is available to a list of members which can be defined on the queue. With a private queue you must be a member of the queue to see the queue items.

Queues can have an email alias, meaning you can create an email address such as support@mycompany.com and have emails to this address automatically routed to the support queue. (We may then also use an automatic record creation rule to create cases as emails arrive on this queue.)

As one example, below you can see an example queue definition. Notice that in this example the queue type is “private” and therefore the queue has a number of members.

Maintain Queues

Whenever a user or a team is created a default queue is automatically created, this is their “local user queue”. This shouldn’t be maintained! But system queues can be maintained in the queues option which can be found in the service management area of the customer service hub. (As shown below.)

Additionally queues can be created from the Service Management area of the advanced settings. Or in business management option within advanced settings.

It is worth understanding that the “queues” option within the customer service hub’s service area actually displays the “queue items”. So when you view a queue from here you see its contents not the definition of the queue.

Below you can see an example of a public queue I have created to handle any incoming support calls. Notice that I have assigned an incoming email address. When you do this an associated mailbox will be automatically created.

Note: Prior to creating this queue I created a suitable shared mailbox in Exchange, thus giving me a generic support email address without needing to create a Dynamics 365 user and consume a license!

When queues are created they are immediately active, they don’t need to be published to enable them. Active queues can be deactivated and reactivated. Queues can be deleted but ONLY if there are no queue items associated with the queue. Meaning that before you can delete a queue you must re-route the items to another queue or remove them before attempting the delete of the queue.

Note: Deleting the queue items removes them from the queue it does not delete the associated record.

The process for creating a private queue is pretty much the same as creating a public queue, except with a private queue you define a list of members for the queue.

Once the queue has been created you are ready to add queue items to the queue. With emails this could be automatically handled on the receipt of a new message, with cases you can use routing rules to automatically route cases to the queue. (Such as automatically move high priority cases to an escalation queue.) These options will be covered later in this post.

Or you can manually route items directly to the queue as required!

Add Cases / Activities to Queues

Now we’ll look at how to manually route a case (or other activities / entities) to a queue. From the case form you can access the “Add to Queue” option. Once selected you and chose the queue you’d like to move the case onto. In my example I have selected the “Urgent Cases” Queue.

Now the case is allocated to the queue, I can see it by looking to the list of active items in the “Urgent Cases” queue. You can also see the details of the queue the case is on by using the “Queue Item Details” button from the case. This will present a screen something like the one below. Notice that this allows the user to see (and change) which user is working on the case. (aka the “Worked by” field.) This field is set as users are assigned to the case or they pick the case from the queue.

Note:
If the case is already assigned to a queue the “Add to Queue” button still shows, in this situation the “Add to Queue” button would effectively remove the case from the first queue and move it to the new queue. A record can only exist one queue at any moment in time.

When we add a case to a queue, behind the scenes nothing is really happening to the case entity. But a new queue item is created on the required queue to show that this case is in the “list” of items to be processed from the queue. You can also move one (or more) items to a queue from an active case view. See below that you can select one (or more) cases and then select the “Add to Queue” option from the command bar above the view. This approach is useful when allocating several items in one go or when you want to quickly move something to a queue without opening the record.

The process for adding activities (or any entity enabled for queues) to a queue is pretty much the same. Although I suggest you experiment with a few entities to become familiar with this process. Below you can see I have added a phone call, case and task to the same queue. This also demonstrates that you shouldn’t think of a queue in terms of one entity type. It would be quite common to have a “support” queue that includes multiple entity types all of which need attention from someone in the support team.

Tip: This does mean I named my example queue badly! As I called my queue “Urgent Cases”. This queue could actually include entities other than just cases, so a better name might have been something like “Urgent Support Enquiries”.

Queue Items

Having routed one or more items, next we’ll look at how to work with the items on a queue.

A queue is simply a list of queue item records. Therefore, a queue is not a collection of records but a collection of queue items. What is routed to the queue is not the record itself but the queue item record. Meaning the queue item is a go-between record sitting between the record and the queue. When a queue is selected from a view the system is actually filtering the queue items by the queue selected. If you inspect a queue item you see no details about the actual case / activity associated, the queue item will simply state who is working on the case and when it entered the queue.

The drop down of queues will contain a list of all available queues, you also have their other options that might be useful to filter queue items. Including looking in all queues, all public queues or all queues the operator is a member of. These options are useful if a single person needs to monitor multiple queues.

Having selected an appropriate queue(s), you can then change the view to show;

all items,
just items you are working on,
items that are available
etc.

Using these views enables an operator to see work they have “to do” and work they “could” do.

The items someone is working on or items that are available is governed by the “worked by” field on the queue items. Meaning you’d either be looking at all queue items with the worked by set to the current user (your to-do list) or all items with a blank worked by (your “could do” list). The worked by field will remain set to the current user until the queue item is completed or the queue item is “released”, which effectively wipes the worked by field and puts the queue item back into the “pot”.

Pick Queue Items

From the queue you use the “pick” option to show when you are working on a case. (or other queue item.) Highlight one or more available queue items then select the pick option, this will present a dialogue similar to the one below. Picking the queue item will assign you as the owner. You then have an option to remove the item from the queue or not. If the item remains in the queue the “worked by” field is also set to show that you are now managing the case.

See below that I left the items in the queue so the “Worked By” field has been set to me.

You can also use the route option to move a queue item from one queue to another. Or in the route dialog select a user (or team) to allocate to the queue item. And again an option is presented to remove the queue item (or not). The owner and worked by fields are then set in the same manner as someone picking the queue item, except the selected user is used instead of the current user. This approach is typically used when a team leader “dishes out” the queue items rather than the operator picking them.

Release / Remove Queue Items

Let’s say you are allocated some cases you can’t do, maybe your about to take a holiday and need to release current activities to ensure that someone else processes these items whilst you are away. This is done by using the release option from the queue. Simply select the item(s) you wish to release and select the release option. This approach leaves the queue items in the queue, “waiting” for someone else to pick them up.

An alternative approach would be to use the “Remove” option. This however would remove the items from the queue. When considering the remove option it is important to understand that only the queue item is removed not the associated case / activity.

Note:
Directly from the case you can add the case or route the case to the queue. But to pick and release the queue items you are required to do this from the queue views.

Case Routing

Another important aspect of managing queues is the concept of case routing. Within a service management environment the use of queues is very common. The ability to automatically route cases is a really effective way to help with the management of queues. The automatic routing might be based on a characteristic(s) if a case, for example all new installation requests to be sent to the installation team’s queue or all high priority requests to be sent to a “High Priority” queue.

Auto-routing can be applied when a new case is saved or whenever a user uses the “save & route” option on the case.

Note:
If you are using auto-save, it is important to understand that the case is not routed when the auto save kicks in! The routing happens when the use selects the “Save & Route” option.

Routing rule sets are defined in the service management area of the customer service hub.

Below you can see an example of a routing rule set, one that hopefully illustrates the concept. I have created a rule set that will assign new IoT cases to my cat! And any high priority cases to my urgent cases queue.

Each routing rule set can have one or more rule items. Below you can see I have opened an example rule item. In this example I am assigning the case to a queue but I hope you can see that I also have an option to route cases to a user. The logic is simple enough, whenever the condition is met the case will be assigned to a team / user or routed to a queue as required.

Tip:
You cannot amend an active Routing rule set, So you will need to deactivate it to make changes. But don’t forget to activate again as only activate rules will be applied when you apply the routing rule.

Enabling Other Tables for Routing

I’m describing queues in the context of service management but it is important to understand that queues could be used by other parts of the business, for example, all fresh leads might be assigned to a new leads new leads queue.

Which tables are enabled for queues can be customized.

Below you can see that I have opened Power Apps (make.powerapps.com) and then opened my invoice table. Here I can access the settings option to control how this table (aka entity) will behave. You will find the options relating to queues under the “Collaboration” heading.

Below you can see I can now use the “Enable Queues” option to allow me to route records in this table to queues. One thing you should be aware of is that if you make this change it can not be reversed. Once a table is enabled for queues it cannot be disabled!

Also notice that we can also opt to add newly created records to the owners local user queue.

In this post I hope I’ve given you enough background information on queues to support your preparation for the MB 230 exam. Queues are actually a simple enough concept but I have found some Dynamics 365 consultants can become confused about how queues operated and when to use them. So as always I strongly encourage you to gain as much hands-on experience as possible. Enjoy!

I have recently moved from using the original Omnichannel Administration app to the newer Omnichannel Admin Centre. If like me you want to use the newer admin experience you will need to migrate your current workstreams. In this post I will explain the process I followed.

As I have configured numerous channels I actually have quite a few workstreams, all of which needed to be migrated to the new admin experience. Lucky me Microsoft provide a tool to help migrate your workstreams to the new unified routing approach. You can find details about this here.

Once I’d download the migration tool I could begin!

Having extracted the tool I simply ran the “URMigrationConsolApp.exe” application. (As shown below.)

Nobody will describe this application as modern looking! In fact it reminded me of something I might have used on a Wyse terminal in the 1980s. (Gosh I am old!!)

Anyway, on running the application I needed to enter the URL of my Dynamics 365 instance and enter my user name. After a short pause I got some lovely green screen style text message telling me I’d connected successfully.

Cool … we have an old school menu! With 4 “real” options and one to exit the application. With a feeling of nostalgia I continued to experiment with each option!

Option One

Option “1” gave me a list of all the workstreams I needed to convert.

Option Two

And option “2” gave me a list of the new style workstreams. Below you can see that I have already migrated one workstream called “BOT Chat”. (The demo live chat workstream came out of the box with the new admin centre!)

Option Three

Option “3”performs a dry run. The description of this option seemed to suggest that it was going to simulate a migration of just one specified workstream. But it actually did a simulation for all workstreams. My simulation didn’t report any errors. Meaning (honestly) this option didn’t give me any real useful information. But still you might want to run it before doing an actual migration. As you may get a different result to me!

Option Four

So option “4” is the one we use to actually migrate the workstreams. You do this one by one. Having selected the option I needed to enter the ID of the workstream.

Tip: I copied and pasted this from the list I got in option 1.

Importantly notice that you are told that after the migration you should only maintain the workstream in the “Omnichannel Admin Center” App. I call the out as you will still see the workstream in the old app. But you should no longer maintain it using the old interface!

I continued repeating this process until all my workstreams had been migrated! As you can see below I was supposed to have no old workstreams remaining!

Conclusion

After the process I tested my various workstreams. So far they have all continued to work as I’d expected. Which is “really nice”!

Afterwards I also double checked that everything had migrated. It hadn’t! I found three workstreams that remained in the old Omnichannel Administration app but didn’t exist in the new Omnichannel admin center.

These three were all connected with my entity channels. These had been created to route cases and leads to omnichannel agents. None of these were available in the migration tool. I guess that means I will need to recreate those at some point. (Although for now they do still work.)

Note: It looks like my entity routing has continued to work after migrating to the newer Omnichannel Admin Center. But as this means I’ll need to maintain my entity channels in the old app and everything else in the new app I will probably want to manually recreate these very soon!

Apart from my entity routing workstreams (which you might not have) …. I am now ready to start using the newer Omnichannel Admin Center. I guess I’m going to need to use the new “Record routing” option to manually re-create my entity workstreams at some point.

In summary the conversion of my workstreams was pretty straight forward. (Except my entity workstreams!) And I am now ready to start to explore what additional features are available in the newer “Omnichannel Admin Center”. Enjoy!

Below you can see an extract from the current skills measured statement that mentions entitlements.

Note: Microsoft do update these exams on a fairly frequent basis. Therefore I do encourage you to check the current skills measured statement to ensure you are aware of the latest information!

Entitlements are a “tool” to help companies manage the services they provide, this post will explain entitlements and how they are used to support service management within Microsoft Dynamics 365. Entitlements are effectively a definition of agreements between the customer and supplier for services to be provided.

Entitlements are used to define the amount of service to be provided (in terms of hours or numbers of cases), the service level to be applied and even what channels the service can be offered upon. It is possible to create a template for your entitlements, so let’s first look at those.

You will find two options connected with entitlements and entitlement templates in the service management area of the customer service hub.

Entitlement Templates

The first thing to note is that the use of templates is optional but they are available to help speed the process of creating entitlements. Using entitlement templates also enforces consistency.

When you create a new entitlement you can opt to create it from scratch or base the new record on an entitlement template.

There are several fields that are important to understand with regard to entitlements (and entitlement templates) as these govern how the entitlements behave;

Allocation Type– determines if the entitlement is based on number of cases or hours consumed.

Decrease remain on– this determines if the balance of support remaining should be decrementing based on cases created or cases resolved.

Total Terms– this is the total number of allocations allowed. (For example 100 cases or 50 hours of support.)

Restrict based in entitlement terms– This options decides if new case creation will be prevented if the entitlement limit has been reached.

SLA– If this entitlement is linked to a specific SLA then this can be defined here.

Note:
An entitlement template can include a start and end date, although typically these wouldn’t be used. As each entitlement created from the template will cover a different period.

You can also optionally define channel and product details within the template if required. These can be used to restrict the entitlement terms depending on the origin (channel) of the case. Or make it specific to services you provide connected with specific products.

Create new entitlements

Entitlements can optionally be created from an entitlement template, as I have already mentioned. It will therefore come as no surprise that the entitlement itself actually resembles the template. Although there are some differences, firstly the actual entitlement will be associated with a customer.

Tip:
There is a third method to create entitlements! As it is possible to create a new entitlement by renewing a cancelled or expired entitlement.

When creating an entitlement, you enter a name, customer as well as a start and end date. (Typically an entitlement will have a start and end date as it forms the contract between the supplier and the customer.) Plus you can associate an entitlement to an SLA. You can also define if this entitlement is the customer’s default entitlement or not.

Note: I will cover the detail of creating an SLA in another post as there is a specific section in the skills measured which relates to these.

As with the template you can define the allocation type (ie number of cases or hours) and number of allotments.

Another option (not available in the template) is the ability to restrict which contacts can raise cases against this entitlement. Useful if you need to tightly control who at the customer is allowed to log cases. For example: maybe only someone from their IT team is allowed to log support requests.

In addition to restricting support based on channel it is possible to limit support to specific products. As your customer’s could have their level of support restricted based on the product or service they have purchased.

Entitlements start off in a draft state and need to be activated. Note, that the entitlement does need to be activated before it can be set as the customer’s default entitlement. The “Set As Default” button does not show in the command bar for draft entitlements! This does mean if the default entitlement is deactivated, maybe because some details need to be amended, when the entitlement is re-activated the default status will have been reset. So you will need to remember to repeat the process of setting it as default.

Entitlement Channels

Channels are optional restrictions on the entitlement, used to limit the amount of support that is provided on a particular channel. You may, for example, limit the number of hours of support provided on the telephone.

Channels are the mechanism the customer used to raise the case. So channels might include email, phone, web portal or web, social media and even IoT. The channel is based on the origin of the case.

It is possible for the total sum of cases allowed on each channel to exceed the total allowed on the agreement. This may seem strange at first but is logical. You might allow someone to log a maximum of 100 cases. With a maximum of 100 being from email, and a maximum of 100 from web and 50 from phone. This doesn’t mean a total of 250 is allowed! The total is the maximum on that channel. So I can log a maximum of 50 on the phone leaving a balance of 50 that could be logged by email or web. (Or I could log none on the phone and log 100 on the web etc.)

Whilst this logic sounds confusing, if you think about it, the purpose is to try to drive customers to have a preference for one channel over another. So in the example I gave we are trying to encourage customers to email requests (or use web) rather than telephoning. This encourages a channel shift that might be very desirable in some situations.

Apply Entitlement to cases

As cases are created the default customer entitlement will be automatically populated onto the case. However, it is also possible to select an entitlement as you may have multiple entitlements for one customer. Maybe reflecting the different service agreements, you have with that customer. It is important to understand that each entitlement is always tied to a specific customer.

Also whilst working with cases the user can optionally decide whether or not to decrement the number of allotments. It might be that a case is raised for a very simple question and the operator taking the call applies some discretion and decides to not reduce outstanding balance of support on the entitlement. Even though you might opt to not decrement the allotment the case would still be associated with the entitlement. As this works well for later reporting of service provided under the agreement and also you may still wish to apply the SLA defined on the entitlement.

If the entitlement is set to restrict cases should the balance remaining on the entitlement reach zero then you will not be able to create any additional cases. One behavior on this you should be aware of is what happens if the balance remaining to decremented on case resolution. In this scenario, if a case is re-opened (unresolved) then the entitlement balance would increment. Giving one extra case that can be resolved.

Entitlements Lifecycle

As already mentioned an entitlement will start off life in draft mode. Only entitlements in a draft state can be amended. You then need to activate the entitlement to be able to start to “consume” the allotment by associating it with cases.

If you activate a contract that has a start date in the future its status will be set to “waiting”. It will then be automatically set to active on the start date. You can only set the entitlement as default once it is active (or waiting).

Once an entitlement has been activated (or set to waiting) it can’t be changed but you can deactivate entitlements at any point. (You must remember to reset as default once re-activated!)

Entitlements that are active or waiting can be cancelled. Once cancelled they cannot be changed and also cannot be used on new cases. A cancelled entitlement can however be renewed.

After the end date of the entitlement has passed it will automatically change to expired.

Cancelled or expired entitlements can be renewed. By selecting the renew button in the command bar.

Renewing an entitlement creates a new draft entitlement based on the expired one. The date range will automatically increment on the new draft entitlement. The draft can be changed before activating the new contract.

To help make this lifecycle clear I have attempted to draw the possible states below!

Note:
We can also deactivate entitlements at any point. This reverts them back into a draft state. (This might be useful if we want to amend an active entitlement and then activate again!)

I hope this post has covered all of the points mentioned for entitlements in the skills measured statement of the MB 230 exam. But as always I really encourage you to get some quality hands-on experience as port of your exam preparation.

I have recently started using Microsoft’s “Omnichannel Admin Center” app to configure Dynamics 365 Omnichannel for Customer Service. This replaces our previous app to administer Omnichannel for Customer Service. The new app contains many features connected with Unified Routing. Some I am still experimenting with! But one feature I have already used to great effect is the new routing diagnostics option. I will explain how in this post.

A key concept with Omnichannel is the idea that we will need to route the right conversations to the right agents. This starts off as a simple theory but in the real-world can quickly become very complex as you add more channels, queues and complexities such as skills based routing and more. This is where the new diagnostics option comes into play to help you understand what has and hasn’t happened as a result of your routing configuration.

For example, I recently wanted to route cases records to my agents. This was simple enough but I needed to only route high priority cases and I wanted to ensure the correct queue was used and for good measure I also routed based on agent skills. This was a reasonably complex requirement but actually quite typical of those real-world scenarios mentioned above.

The “record routing” options in the new style admin center have changed slightly so as I created my routing config my cases didn’t route as I expected. (All because of user errors on my part!) But this turned into my first chance to use the new routing diagnostics option.

The diagnostics option is connected with Unified routing and can be found in two places! Firstly you will find it in the Omnichannel as shown below. But you can also find it in the Service Management area of the customer service hub.

Initially the diagnostics will not be running, so your first task maybe to turn them on. Once that has been done whenever you try to route a conversation or record to one of your agents a record will be created in the diagnostics view.

For example, below you can see that I have routed a customer conversation on my portal. In this example the chat wasn’t routed directly to a human as from the chat widget in question I routed to my BOT instead.

The diagnostics let me see that a conversation was started. The status of “agent assignment – completed” indicates that the routing process completed and the conversation was assigned to an agent. (In this case a virtual agent!) I can also see which workstream was used and which queue the conversation ended up on. As I mentioned at the start just knowing your workstream and queue sounds simple but with many active workstreams and queues just understanding which conversations ended up on which queues is essential.

Lets return to my initial issue of routing case records. As I was setting up my workstream and routing rules I hit a few issues!

My actual results are shown below. You can see that it took me five attempts to get my routing exactly right.

In my first two tests I hadn’t correctly defined which records I wanted to route. The “Intake rules” were completing but the result of those didn’t route my case to a workstream or queue. My third attempt improved as my case was routed to my case workstream but it ended up on my default queue. Technically this had worked but wasn’t the result I wanted.

Test 4 was user error. Whatever I did to improve my routing was a mistake as it went back to not trying to route my case! But with test 5 you can see that I finally got things right and my case routed my correct workstream and queue.

So just having this high-level information of how far the routing got and which workstream / queue my case ended up on really helped me see the mistakes I’d made.

But there’s more …. Much more!

Below you can see that I have opened one of the diagnostics records created by my tests. Here I can see much more useful information. This data will show you exactly what has happened and should be really valuable in identifying any issues.

You can see that I have a number of “tabs” which explain the details of what happened at each stage in the routing process. I also have a summary tab which actually might show you most of the information needed!

When “something” is routed several stages are applied on order. Depending on your routing setup some or all of these may apply. The stages are;

Intake– intake checks any conditions and routes your item to a workstream.
Classification– you may use a ruleset to classify how the item is to be routed. In my example I classified items based on skill levels.
Route to queue– next the ruleset will route your item to a queue
Prioritization – selecting an agent from the queue has a prioritization ruleset you will see which rule set was used here. (Note: I just used a simple method of routing based on agent capacity, so this stage wasn’t needed. But prioritization might be done on a first in first out basis or maybe it could be based on created on date or maybe my cases could have been prioritised based on their SLA.)
Assignment selection– As I was always routing based on capacity I didn’t need this stage. But I could have conditionally assigned to agents based on several other methods including a “round robin”, “capacity”, “proficiency” and more.
Assignment – finally an agent is assigned based on the selected assignment method. (Notice mine is based on capacity!)

I guess our aim is to ultimately end up with the assignment stage completing! Along the way the routing could stop or you could end up diverting the item to an incorrect queue etc. (As I did!)

When viewing the summary if you identify that any stage did not work as expected you can open a tab specific to that stage to see exactly what rule was applied. For example, below you can see that in my intake I only route cases that have a high priority. One of my many initial mistakes was I’d got this condition wrong so my cases weren’t being routed to the next stage as expected. The diagnostic tool allowed me to see exactly what was happening as cases were created and I quickly managed to fix this condition.

Hopefully you agree that having this diagnostics option to understand how you Omnichannel routing (Unified routing) is operating is an essential tool. I am already wondering how I previously configured my routing without such a tool!

You can read the Microsoft documentation about the diagnostics for unified routing here. Enjoy!

Customer Service Workspace for Microsoft’s Dynamics 365 gives us the ability to open sessions and tabs in customer service scenarios. This can be very useful when an agent is juggling resolving multiple cases simultaneously. When they open a case it will be common to open the customer record, in this post I will show how we can always open the customer record and therefore save a few clicks. And in doing so, I will introduce several concepts including the app profile manager, session templates and application tabs.

App Profile Manager

Firstly I would like to mention the App profile manager. As I am going to use this for my example ….

The App profile manager allows me to create profiles which in turn I can assign to users. This gives us an approach to customize the interface for specific users. Some of my users may require particular behaviour when a session starts, maybe some want the productivity pane to be open by default, maybe some need access to specific communication channels etc etc.

You may already be using Customer Service Workspace or the Omnichannel for Customer Service apps without using the app profile manager! This is probably working fine as any user not assigned to a specific app profile will be using the default app profile. If you apply any customizations to the behaviour of the Customer Service Workspace app I advise you to consider using the App profile concept. You can of course start off with just one profile but by using the App profile manager adding suer specific customizations later will become an easy process.

Something else that is really cool about app profiles is that they are solution aware. Meaning you can migrate them from environment to environment.

Below you can see I’ve opened make.powerapps.com. I have used the app option to find my “Customer Service Workspace” app. It is from here that I can open the “App profile manager”.

Initially when you load the App profile manager you will be presented with a screen something like the one below. If this is your first time loading the App profile manager you will probably want to use the “create an app profile” option to start creating your first profile. Or you can use the “See you app profiles” option to open a list of your existing app profiles.

If you are creating a new app profile, you will need to give your app a name. Then specify a unique name.

Tip: The app unique name needs a “publisher” style prefix, say “neil_”!

Now your app is available and you can start to customize it.

Example Session Template

Whenever I consider a new feature like this I like to work with an example. Hopefully showing how an example session template will work I can help give you ideas for your own sessions.

Note: In my example I am going to focus on session templates but you should be aware that within my app profile I can control the behaviour of the productively pane. I can also define which omnichannel or third party channels I might want to include in this profile. Say some of your users need access to web chat and others don’t then you can use this feature to support that requirement.

In my example, whenever a user opens a case I want that case to open in a new session. I also want to make the title of the session the case number.

But I would also like to go further, as whenever the case opens in a session I would like a second tab which will include the customer associated with the case. Not forgetting that sometimes that will mean opening a contact and sometimes an account.

If I have an existing session template I can search for that and include it in this profile. Or I can use the “+Add entity session templates” option to create a new one. (As shown below.)

Below you can see that when I click the “…” option on an existing session template I can open it in the Unified Interface or remove it from this profile. Opening in the Unified Interface will open a fresh browser tab containing the session template and access to all of the other Customer Service Workspace options.

Below you can see that I have created a customer session template. I will give more detail of each field below!

Field	Details
Name	“Custom Case Session” This can be anything you like, it describes the session template.
Unique Name	“neil_CustomCaseSession” The format is important here! You need to add a prefix which will normally be your publisher. So in my example “neil_”.
Type	“Entity” Two types of session exist. In my example I have used “entity” as when a user opens a case entity (or phrased another way a case table row!) then we want a session to start. The other type of session is a “Generic” session. We use that with Omnichannel for Customer Service when the session start will happen as conversations begin.
Entity	“Case” Assuming your session type is “Entity” then you will need to specify which table triggers the start of these sessions.
Title	“{anchor.ticketnumber}” We can optionally add details of how to name the sessions as they open. If you leave this field blank then the primary field from the entity selected would be used. Typically this would be a name field or in my case example the title of the case. But in my example I didn’t want to use the title as the shorted ticket number seemed like a better field. I have surrounded the “slug” in brackets. And also added the keyword “anchor.” before the name of the field. This is because we can reference fields from the tab used to open the session by adding this “anchor.” prefix.
Communication panel mode	“Hidden” In my example the communication panel is hidden. Other options include “Docked”. We’d probably want to see a communication panel on a generic session that has been started as a result of an incoming omnichannel conversation. But in my example I don’t need the communication panel, hence the setting of hidden.

Having saved my session template I can add additional details. These may included which agent scripts to load at the start of the session. Or like in my example, any additional tabs you’d like to open. As each time my session opens I wanted to also open a tab contain the customer from the case.

Therefore I created an Application tab and added this as an additional tab on my session. I have shown my Application tab below. And again I will give you some additional detail below!

Field	Details
Name	“Customer – Customer Application Tab” This is simply a descriptive name for my tab.
Unique Name	“neil_customcustomer_applicationtab” Like the session template the format is significant here! You need to create a unique name that is prefixed with your publisher. So in my example “neil_”. Note: This idea of creating a unique name that includes the publisher prefix should start to make more sense when we add our app profile into a solution. As then the names for our templates will be following the same naming convention as other assets in our solutions.
Title	“Blank!” In my session template I completed the title field. As an example in my application tab I left the title blank. This is because I was happy to name the tab as the customer being opened.
Page Type	“Entity Record” In my example I want to open an application tab containing a Dataverse table. (aka entity). But I could have selected one of several different page types. Including an entity view, web resource, dashboard and more.
Description	“Blank!” I didn’t enter a description. I was being lazy! In a production instance it might be useful to enter details of how and when this tab will be used. As that might aid future maintenance.
Can close	“No” When my customer tab opens I want it to remain open until the session is close. By entering “Can Close” as “No” I prevent the users from closing this tab.
Parameters	Depending on the page type different parameters may exist. Having saved my application tab as I had select “Entity Record” I have a set of standard parameters. These included “createFromEntity”, “data”, “entityID” and “entityName”. In my example I want to open an existing customer record into the tab. The customer many by a contact or account. So I need to supply two fields, one being the GUID of the record to open and the other being the type of table (entity) I want to load. Both of these fields can be “grabbed” from my anchor tab. Which will be the case I am opening. Set the “entityID” to “{anchor._customerid_value}”. This will be the GUID of the customer I want to open. Set the “entityName” to “{anchor._customerid_value@Microsoft.Dynamics.CRM.lookuplogicalname}”. This will be the entity type I am trying to open. So “account” or “contact”.

Assign Users

Having completed the definition of my app profile, I can now add users. These will be the users that will use this profile in preference to the default App profile.

Below you can see that I have opened my App Profile and selected the users option.

A screen similar to the one shown below will open and you can add users into this profile.

Testing

Once I had completed the above changes I opened my “Customer Service Workspace” app. You can see below that by default I have my customer service agent dashboard open.

Opening a case into a new session from this dashboard or any home page will start a session.

Tip:
Out of the box use “shift and click” to open your case into a new session. Or configure the simplified interface option that will open all records opened from a home tab into a session.

As my case opens in the session several things happen!

Firstly notice that the session name is not the title of the case. As above I set the session title to be the case number instead.

Also notice that a second tab opens that contains my customer record.

And when I click on my customer tab notice that I don’t have the ability to close the tab. Meaning the user is forced to keep this tab open until they have finished with the case and close the session.

Solution Aware!

I mentioned earlier that app profiles are solution aware.

As a test I created a solution. You can see that I then used the “Add existing” option. Here you will find an option called “App profile”. So I used that to add my custom app profile into my solution.

Next I used the add required components option on the app profile I just added into my solution.

You can see below how my application tab and session template that had been included into my App Profile are now added into my session for me. I could (of course) have added these components manually but I found using the “+ Add required components” option made my life really easy!

I can now export my solution and import it into other environments as required.

Hopefully by showing this example I have introduced you to the Customer Service Workspace and shown how I can use the App Profile Manager to customize my agent experience. I hope this example has proved useful and that you can adapt this idea for many other purposes. Enjoy.

We have our next “Birmingham” Dynamics 365 event planned for Wednesday 19^th May at 5:30pm. This is a free virtual event so open to everyone.

Everyone can register on meetup here for free.

Our next exciting Dynamics 365 Birmingham User Group meeting will be taking place on Wednesday 19th May 2021 at 5:30pm, and we would love to have you along!

We hope to see our local friends. But being a virtual event EVERYONE will be very welcome.

This time we have two amazing speakers. But I would think that … one of them is me!!!

Session : A new & unique approach to data cleansing in D365
Speaker : Ben Warren, The Software Bureau

Ben Warren, from The Software Bureau & Clean Contacts will join us to describe their data cleansing tool. Every business has to clean their data, but the current methods can be complicated and risky. Clean Contacts enables automated data cleansing of UK consumers – identifying where an individual has moved, where they have moved to or if they have passed away.

Hosted within MS Azure, with no data having to leave the environment to ensure maximum security, and integrated into D365 using the Power Platform.

This session will provide an overview of the solution and demonstrate how a D365 user can gain total peace of mind.

Session : Customer Service Workspace
Speaker : Neil Parkhurst (aka me!!)

Dynamics 365 now includes several user interfaces your customer service agents may want to use. I’m sure you know we already have Customer Service Hub, Unified Service Desk and Omnichannel for Customer Service.

Customer Service Workspace is the newest kid on the block! So what does it offer and when might you use it in preference to these existing established options.

In this presentation you will see a demo of the Customer Service Workspace. And additionally the App Profile Manager and more!!!

Everyone can register on meetup here for free.

In this post I will cover;

Advanced similarity Rules
Record Creation and Update Rules
Case Routing Rules

In a future post I will cover;

Case resolution form
Status reason transitions
Busines Process flows

Note:
I will leave “Customer Voice” for a further post as that “feels” like a bigger subject that deserves its own post.

Similarity Rules

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!

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.

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

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.

You might want to send all high priority cases to a particular queue or assign all major complaints to your complaints manager.

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.

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.

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.

Record Creation Rules

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.

Tip:
You might find this article from Microsoft useful!

Automatically create or update records in Customer Service Hub (Dynamics 365 Customer Service) | Microsoft Docs

Rule Creation

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!)

Having defined my condition I now say which type of entity I need to create.

Tip:
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 already covered the following topics in a previous post;

Similarity Rules
Record Creation and Update Rules
Case Routing Rules

In this post I will focus on;

Case resolution form
Status reason transitions
Busines Process flows

Note:
I will leave “Customer Voice” for a further post as that “feels” like a bigger subject that deserves its own post.

Case Resolution Forms

Standard Dialog

Customizable dialog

Next we have the customizable case resolution dialog. At first glance it will look very similar to the standard dialog!

Quick create dialog

Below you can see an example of the quick create dialog. Notice that the user experience is slightly different but until I customize the quick create form the fields is identical.

Tip: This post from Microsoft includes a description of a possible way we might want to customize the resolution process.

Status Reason Transitions

Before considering status reason transitions you should ensure you understand the concepts of status and status reason.

Status… the status is the “ultimate state” of a record. Typically the values cannot be customized and for most entities just two states exist. (Active and inactive.) Although a case can be “Active”, “Resolved” and “Cancelled”.
Status Reason … the status reason field shows the reason for a particular state. For example, an active case can be “In Progress”, “No Hold”, “Waiting for Details” and “Researching”. You can customize the options in the status reason! (Meaning you can add additional reasons as required.)

Below you can see that I have clicked on edit status reason transitions and I have enabled the feature. Now, for each status reason I can define which reasons can be selected.

This article from Microsoft might be useful when reviewing status reason transitions …. Define status reason transitions with Power Apps – Power Apps | Microsoft Docs

Business Process Flows

You can see which is the current stage as it has the “double circle” icon. Usefully we can see how long this case has been paused at this stage. Completed stages are marked with a tick.

Clicking on a “stage circle” shows the steps (or fields) which need to be completed before progressing to the next stage in the business process.

The out of the box business process flow on cases includes the following stages / steps;

Stage	Steps
Identify	Find customer (Mandatory) Find Contact
Research	Assign to Others (Mandatory)
Resolve	Mark as resolved

Business processes help to provide a consistent approach to handling cases. They can also contain conditional branches giving the ability to handle multiple scenarios.

If you wish to find out more about amending business process flows …. you could refer to this post for more information on business process flows.

The steps involved in creating the third stage are as follows;

Step One – Create a two stage SLA!
Step Two – Create a lookup to “SLA KPI Instance”
Step Three – Create a “Resolution planned” column
Step Four – Create a quick view form and add to case form
Step Five – Create third stage in SLA KPI
Step Six – Create SLA