Advanced | Flow of the Week: Automating Intelligent Customer Service using Microsoft Flow, and Dynamics 365

As organizations focus on customer obsession, they need to scale their organization to exceed elevated customer expectations. It typically isn’t practical to meet this demand through additional headcount. The question becomes how can I scale my customer service department, without adding labor costs? The answer lies in the phrase “work smarter, not harder”. To achieve our new customer service goals, we can leverage Microsoft services like Microsoft Flow, and Dynamics 365.

A strategy we want employ is to better understand the types of issues our customers are having as soon as possible. If we can interpret their intent, we can ensure the correct people within our organization are aware of the issue, to provide a more timely outcome. But, to achieve this, we need some intelligent technology. Fortunately, we can take advantage of which will understand the customer’s intent so we can route this information correctly.


A power company, called Contoso Energy, would like to improve their customer service and wants to provide many channels for customers to solicit assistance. In addition to mobile, social and telephone conversations, they continue to receive customer support requests over email. Sifting through emails manually to log support cases inside of their ERP (Microsoft Dynamics 365) is a time consuming and low-value activity. Especially, when you consider the people that can help solve the customer’s issue, are not immediately informed of the issue.

As a power company, there are many customer requests that can be made including reporting a power outage, billing queries, street light replacement and vegetation brushing to name a few. Some of these requests are higher priority than others so it is important we understand the user’s intent when we log the support case. This allows us to prioritize their case correctly and ensure the right department can address high priority incidents asap!

Solution Overview

To achieve their goals, Contoso Energy is going to use Microsoft Flow to automate the retrievals of emails that are received in the customer service inbox. Instead of an employee reading, and reacting, to these emails, Microsoft Flow will apply a filter on specific keywords. Next, the body of the email is passed into our LUIS connector. LUIS stands for Language Understanding Intelligent Service and uses machine learning to allow people to build applications that can receive user input in natural language and extract meaning from it. We will use LUIS to interpret the intent of the email that our customer has sent us so that we can log it appropriately within our Dynamics 365 case. If the customer concern is a high priority, such as a power outage, we want to let our Field Services know right away. This way, they can prioritize the resolution of the incident. Once we have created our case within Dynamics 365 and made the impacted department aware, we will acknowledge the customer’s request by sending a follow-up email that includes their case number.


Before we work on our flow, we need to build our LUIS application. We can access the LUIS service from LUIS has been covered in a previous Flow Blog post, so please refer to that post if you are new to creating LUIS applications. 

Within LUIS, we are going to define four different Intents:

With our Intents defined, we need to go into each one and provide some utterances. Utterances are related statements that infer an action, in natural language, provided by a user. In our Power Outage Intent, we will describe some sentences that we expect to receive via email that imply there is a power outage. The more descriptions we provide, the more accurate our LUIS model will be.

Once we have created our Intents and Utterances, we can then test and train our application.

With our testing complete, we can publish our application to a Staging or Production Slot.

After our application has been published, we will have access to a starter key and an endpoint URL. We can use this endpoint to perform additional testing through a tool such as Postman or from a custom application. To call LUIS from flow, we need to copy the Key String.

Microsoft Flow

Our flow will be triggered when a new email arrives in our customer support mailbox. We can include a Subject Filter if we are controlling how the email is created, such as an email form on a web page.

If we expect our emails to be received in Html format, we can use the Html to text action to remove the Html markup so that when we insert the content into Dynamics 365, we are not including this additional formatting.

Next, we will pass the text output to our LUIS action where we will provide this text as our Utterance Text. In this case we do not have a Desired Intent, so we can leave that blank.

We will use the Top Scoring Intent that LUIS identified throughout the rest of our flow, so we will create a variable called Intent where we can store this String value.

With our interactions with LUIS complete, we can now focus on Dynamics 365. When we create a Case for our customer, we want to be able to link it to an Account. To do this, we will call the List records Dynamics 365 action and provide a Filter Query of emailaddress1 eq ‘From’.

Next, we need to perform a validation to ensure that we found a record, prior to logging a Case. This validation occurs by using the length expression and passing in the body(‘List_records’)?[‘value’] from our List records response message. If we don’t find a record, we can simply send an email escalation to a Customer Service group mailbox. If we do find that a record exists we will continue with our process.

With a customer record found, we will now go ahead and create a Case within Dynamics 365. Within the Create a new record action we will pass in our LUIS-derived Intent as our Case Title, specify the Account (id) as the Customer and our inbound email Body as our Description.

Now that we have a Case logged within Dynamics 365, we want to inform the respective groups if this is a high priority case. To determine this, we will pass our Intent into a Switch statement. There are two events that we are focused on: Power Outage and Billing. 

Should the Intent be one of these types, we will post a message to the appropriate team’s Microsoft Teams channel. Within this message, we can include our Intent, Account Name, Case Number and Description.

There is nothing worse than creating a Customer Service Case and not getting a response. So let’s ensure our customer is confident that we have received their request by echoing their original request and providing the Case Number via an email.


Our flow is now complete, let’s now test our automated business process.


Let’s construct an email that includes a subject of Customer Support Request so that our email filter catches it.

Let’s now look at our Run Details to see how LUIS interpreted our email. In this case LUIS correctly determined that the incoming ticket was related to a Power Outage.

Now, we can log into Dynamics 365 and see that a new case has been created that has a Title of Power Outage. It has also correctly linked our customer’s Account.

Within Microsoft Teams, we also see a new message has been posted in our Power Outage channel.

Lastly, an email was sent back to the customer acknowledging their request and the Case Number for their issue. 


The entire duration of this automated business process was six seconds. Yes, six seconds! Now, in this case we haven’t just arbitrary logged a ticket within a Customer Information System, but we have understood the intent of the customer request and prioritized it to ensure we can get the right people focused on the problem as quickly as possible.

This was all possible without writing a single line of code, provisioning infrastructure or requiring a deep understanding of machine learning technology.

We hope you enjoyed this content. If you have ideas for templates or other feedback, please leave us comments below or post on our Community forums.