Connecting LUIS to D365 (Part 2)

In the first part of this blog post I explained our scenario for Big Energy Co and it’s desire to improve efficiency in the support desk, introduced LUIS and the core concepts around utterances and intents, configured LUIS to allow it to understand the intents we need and published the application.

Now I need to connect LUIS and D365 to allow automatic classification and routing of cases based on Natural Language inspection of the body of the case.

This blog has at least 3 parts, but overall the posts objectives are

  • Give you an understanding of a real-life scenario where we could implement LUIS (Part 1)
  • Introduce you to the concepts of LUIS (Part 1)
  • Discuss the Microsoft Flow to connect LUIS to D365
  • Give you some next steps on how you can try to bring LUIS into your organisation

Nowadays, Microsoft Flow doesn’t need an introduction – it is the cornerstone for the whole of Microsoft Power suite (not sure why it doesn’t get the Power prefix) and allow spot integrations between one or more disparate applications. It also allows you to “program” some data transformation or logic to control how data flows between applications or actions to take in specific circumstances. Flow is a complex beast, but simple to use in a lot of cases.

The Flow

As you can see, the flow is pretty simple. We get a trigger from D365, strip the body of the case down to raw text, check to see if have anything left, ask LUIS to predict what it is, check how confident LUIS is, then update the case again. This is a simple flow which isn’t production ready by any means, but shows you the power of Flow and is enough for you to get started

Triggering from D365

Our first step the trigger from D365

I am using the Common Data Service connectors here, which are the future, so why not? We have to connect to our D365 environment, chose the Cases entity and give it a scope. This is new for the CDS connector and allows a lot more flexibility around what data runs through a flow. You could keep the data to one business unit in an organisation, useful if you have country specific flows for example.

Stripping that nasty HTML

Email contains lots of formatting information that LUIS doesn’t understand. CSS, html tags, that heading etc will really upset LUIS, but handly there is an action to return just the actual words. Pass the body of the email, the case description to it.

Also in this snippet, I am setting up a variable for use later on, to store the Subject ID.

Checking for empty email

Another thing that LUIS doesnt handle is sending it an empty request. Just for a bit of house keeping, if, after stripping out all the html tags, the content is empty, rather than calling LUIS, exit gracefully. Always have in mind when running any flow that someone will be bombarded with error alerts if you don’t check

Passing to LUIS

In the previous post, when your LUIS app is published, you get a GUID representing the Application key. When you first connect to LUIS in Flow, this is what you need. If you have many applications in LUIS on that key, Flow wants to know which one, and also which version. This is handy if you are training LUIS and the new version isn’t quite ready, stick with a previous version of your app.

The Utterance text is the email body, stripped of the html, which LUIS is to analyse.

Is LUIS confident?

Like any AI product, LUIS can only predict what it thinks is the likely intent of anything you pass to it. It provides you with a score, 0 being not confident, 1 being overly confident that matches each intent. We basically use this as a percentage. When this returns to flow, LUIS provides the top scoring intent as well as the top scoring intent score. If LUIS isn’t confident that what you have sent it, then Flow shouldn’t update the case. This case should stay with the 1st line queue for them to resolve.

Again, this is about making your code production ready. It would be quite easy to trigger additional steps here to ensure this case is looked at and maybe a training point for LUIS after a human decides on the best route for the case.

Retrieve the subject

The subject tree in D365 matches the intents. This is a key point for our process to work. You could use other factors or matching, but this is pretty simple.

Using the CDS link, we use the List Records feature to query the Subject entity. The filter query is the key here, using a piece of OData query notation to find the subject with a title that matches our top scoring intent.

Though we will only retrieve one record, the List Records action will always return an array or records, an array of one. To keep your flow in one column, you can set a variable with the value of the subject Id you have retrieved and use this going forward. If not, you will have to do the remainder of these steps within the Apply to each action.

Updating the Case

The last part of this simple flow is to update the case back in D365. Using the Id from the originally triggered case, we update parts of the case.

The description is updated with the html stripped text. There are lots of ways to do this in D365, but seeing as we have done it already, it is neat to use it again. I have also added a new field on the case to log how confident LUIS is. This could be used as a summary later or for managing the training of LUIS.

Finally, the subject Id is passed to the Subject field.

So that is our flow complete. Now for some testing.

Testing our Flow

Flow has some really neat tools to ease testing. In the right corner, is the Test button which gives us this panel. The first time you run a flow, you will have to perform the trigger action, sending in an email to convert to a case or creating a case in our scenario, but after that, we can use previous data. Great for tweaking & checking

If you run a test, you will hopefully get a screen with lots of green ticks next to the parts that ran successfully as well as some crosses against those that didn’t.

If you drill down to each step, you can see the input and the output from that action.

In this example, you can see the original html formatted input from an email as well as the output of just the text.

The call to LUIS shows the JSON return from LUIS. The LUIS connector gives a lot of properties transformed out of this content.

The CDS record update shows only the fields that we update, a standard D365 API call. You can see the Subject ID being set, as well as the html stripped description and the Intent score.

So, flow done. In the next installment, I will show the D365 implementation, how we bring it all together. I also take LUIS and flow a little bit further, to add more complexity and functionality to the both to improve the scenario.

Connecting LUIS & D365 (part 1)

As Microsoft wants us to consider using AI in all aspects of our developments, I wanted to see if I could use one of the cognitive services available to life in a real life scenaro.

This post & it’s other parts will

  • Give you an understanding of a real-life scenario where we could implement LUIS
  • Introduce you to the concepts of LUIS
  • Discuss the Microsoft Flow to connect LUIS to D365
  • Give you some next steps on how you can try to bring LUIS into your organisation

The Scenario – Big Energy Co

Imagine a busy helpdesk or contact centre at one of the big electricity or gas companies. They are inundated with calls, emails & chats from their customer base to request numerous changes or additions to their account, provide meter readings, complain or numerous other concerns.

Email is one of the biggest mediums for support when the matter is not urgent. The standard email to case conversion is commonaly used to bring these support requests into D365 CE.

But that is traditionally where it stops. A 1st line support user would have to read the content of the case, decide on the appropriate subject for the new case & select save and route. This takes time, upto a couple of minutes, of invaluable time of an educated, talented member of your team.

LUIS – Language Understanding

LUIS is Microsoft’s cloud-based API which tries to understand the meaning behind phrases. LUIS could take a paragraph of text and categorise it to suggest what the writer of the paragraph is trying to say. Bringing machine learning into your app can drastically reduce the time spent scouring tet for meaning .

In a 1st line support scenario, an email comes into a support mailbox and D365 will create a case with it’s auto-creation rules to allow a 1st line support person to read the email, decide what the email is concerning, then route the case to the relevant team.

Using Flow and LUIS, we can automate this step, reducing the time taken to get the case to the right people, improving SLAs and reducing costs.

LUIS Configuration

For all of this, I am using a trial environment, Microsoft makes it easy for you to play with all it’s tools, and LUIS is no exception. The free licenses gives you 5 text requests per seconds, definetly adequate for development and trial purposes. It is then £1.11 per 1000 transactions above this, with a max of 50 transactions a second.

By going to & logging in, you will be allowed to create an app. This is the starting point. As you can see my app has been created already.


Intents are the term for meaning within the app. Each app will have several intents, what are the likely short description or categories of why an email would come into the environment?


Each intent has several utterances, which are phrases from which LUIS will learn and define the intent of the text passed to it. It is very simple to add utterances and you should aim to get 15 or so for each intent as a starting point.

You can add as many utterances as you like, try to keep your utterance count consist between intents as a higher utterance list on one of the intents will lead to it be chosen more, in effective giving you false results. When you get into a near production scenario, you need to keep adding them from feedback from your users. You could enact a process which, when LUIS fails to assocaite an intent to a case or gives a false classification, this is highlighted for a BA to analyse & apply to the model.

The next thing to do is train LUIS. This brings any changes you have made into the AI so they also can be used to understand the conversation.

Training is complete when you get a green bar across the top.

Now we have a model, let’s test it, using the inbuilt Test functionality available from the top right.

If you type a string in the box provided & hit return, you are calling LUIS and the text will be analysed and LUIS will reply with the highest intent & how likely the phrase enters matches it.

I have entered the phrase “can you help me transfer my account”, which wasn’t part of the utterances I created earlier, but closely matches one of the Account closure utterances.

Looking at the response, LUIS is stating that he thinks this phrase is about Account Closure and he is 58% sure that this is correct. If you click on the Inspect link you can use this to train LUIS if the response is not correct by using the Edit link, adding an utterance to one of the other intents or reenforcing the entered text was in the correct intent.

Publishing LUIS

My LUIS app is ready, it is trained and raring to go. Now we need to allow access from the publicly available API. The Publish button steps you through the process, ensure you go to Production. Don’t worry about costs for now, you get 5 requests a second for free, which is great for trialling & developing

In Application Information, there 2 key bits for connecting LUIS to Flow. Firstly, the Application ID is the key we want later. Secondly, we need to ensure anyone with the Application ID can access our endpoint & use the app we have configured, so ensure the Make this app public is checked.

This is a little less secure than you would want in production and there are details about LUIS security available to ensure only the proper users can access fully documented here.

That’s it, ready to go. In the next part, I will configure D365 and Flow to complete the scenario