In this 3rd installment of the series devoted to using Language Understanding (LUIS) to categorise emails via Flow, I will describe some of the parts of the D365 solution and walk through a final version of the Flow to extend its capabilities.

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 (Part 2)
• Give you some next steps on how you can try to bring LUIS into your organisation

Routing the case

Standard Save and Route functionality only fires automatically on case creation, or when a user manually hits the button. This action is available in workflow, but not in the CRUD actions of the D365 or CDS connectors. To get around this there is a workflow triggered of the change of the subject field which calls the OOTB action ApplyRoutingRule. This effectively is the same as the user clicking the button.

The routing rules are very simple, routing the case based on the subject selected.

Adding information from the case

In our scenario, based around a support desk for a large power company, one of the common requests is to provide meter readings. This data is invaluable.

In LUIS, this information is called an Entity. You can configure entities for each of the Intents to denote some parcel of information that the user is telling you on top of the intent of their email.

As you start typing and enter data, LUIS recognises this and replaces the data with a data type that it will use.

In Flow, the return from LUIS will contain a list of all the entities it has found in your utterance. The flow then updates the case with this defined data, in a separate field on the case record.

The first part of the flow checks the length of the array of entities that LUIS returned. If there are no entities, then just do a normal update of the case record. If there are entities, loop through them

As the entities array is looped through, check that the entity is a number. LUIS could return you a date or name. If it is not a number, just do a normal update of the record.

If it is a number, pass the meter reading to the case update in the new field on the Case entity.

This approach does lead to duplicate updates, 1 for each entity it finds. You may be better suited to extend the logic in a production system to prevent this.

Auto-reply for common intents

In our scenario, one of the common requests that the help desk gets is to ask when the end user is due a bill. This again could be dealt with in numerous ways via workflow in D365, but doing it in Flow allows the demonstration of Flow’s abilities.

The first part is to check the Top scoring intent is “Next Bill due”. The flow goes on to check for meter readings if it isn’t.

Using D365 connector this time (Microsoft changes so quickly, it is hard to keep up with what the best methods are) I retrieve the contact that created the case then send them a nicely formatted email. This will send the email as the account you attach to run the flow, in our scenario the support desk. I have only hardcoded the content here, but you could easily read the date of the next bill from the users account record or something similar.

The next step is close the case as we have provided the end user with the appropriate information. In D365, this is another action not readily available via the CRUD of the CDS or D365 connector.

I now realise, after attending the EU D365 User Group Summit that this would be possible via Flow, along with routing the case, if you create your own custom connector and associate that with your D365 API instance, but that’s for another post.

To get round the limitations, a new field is populated on the Case record, Close from Flow.

A workflow is then triggered when this field changes to call the OOTB action if the value is true.

Sentiment analysis

One of the big uses for social engagement and monitoring is to assess sentiment in the comments made by customers. LUIS provides this information in a textual (positive, neutral or negative) as well as numeric form if enable it on the application.

Once you have this configured, recording this against the case and maybe setting a priority on it’s value would be quite straight forward.