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.