Intelligent automation with Logic Apps and LUIS

Intelligent Automation is a hot topic these days as organizations look to extract even more value out of integration investments by including intelligent, machine learning-based solutions within their interfaces.

In fact, KPMG is anticipating the intelligent automation marketplace will be worth more than $231 billion (USD) by 2025.

So how can we take advantage of Intelligent Automation with Azure Logic Apps?

The answer is to include the Language Understanding Intelligence Service (LUIS) in our solutions. LUIS is part of the Azure Cognitive Services offering and is able to predict the intent of a message through the use of machine learning. The best part of LUIS is that it is not a complicated tool to use, but is extremely powerful.

To use LUIS, we need to create an account on LUIS.ai and create an application. At this point we need to think about what we want LUIS to predict for us. In our scenario, we are going to get LUIS to process emails that are sent to a Service Desk.

Once we have our application created, we can then create Entities. Entities will allow us to be able to map the type of request that our end user is requesting. For example, we know that our users will be creating a ticket, but more specifically, we need to know what type of ticket they are trying to create so that we can route it to the appropriate team. In our example, we will create entities for Hardware, Mobile, Network, Security and Software.

Next up, we want to create an intent of Create Ticket. An intent represents an action that a user would like to perform. If we wanted to create additional Intents, we do have the ability to do so, but isn’t required for this example.

LUIS uses a ‘train-by-example’ model to predict user intents. So what we need to do here is to type in different examples and then map our entity to our intent. For example, we can type in I forgot my password. We now want to map password to one of our entities so that we can create a ticket that will help resolve the user’s password issue. In our example, using the Security entity is the best fit. To map this, we simply click on the word password and then select Security.

We now need to Train and Test our LUIS application. Once we are happy with our results we can then Publish our model and get our API key that we will need in Azure Logic Apps.

To get our API key, we need a published application and then can click on Manage and then Keys and Endpoints where we can copy our Authoring Key.

Within Azure Logic Apps, we will add an Outlook.com Trigger where we will add a Subject Filter of Create Ticket so that we don’t try to retrieve every email from our Inbox. We will also add a Get prediction action which belongs to the LUIS connector. To establish a connection to LUIS, we need our Authoring Key which we retrieved in our previous step.

When we call the Get prediction operation, we get two arrays returned: Intents Array and Entities Array. In our scenario, our intent will always be a Create Ticket intent, but we are more interested in the Entities array as that will allow us to log a ticket in ServiceNow using the correct category. Detected entities will be listed in order of an accuracy score. We also don’t know how many nodes within our Entities array will be returned. As a result, we need to perform some JSON operations so that we can get the first node in this array. To put some structure behind this LUIS response we will use a Parse JSON action.

If no entities are detected by LUIS, we will receive an empty array. As a result, we need to detect this and can use an expression inside of a condition that detects how many nodes exist.

If we do have one or more nodes in our array, we will then go ahead and parse the Top Scoring Entity using a Parse JSON action. Microsoft makes this really easy to accomplish by using the first function that is part of the Logic Apps Workflow Definition language.

Now we can use LUIS’s prediction to feed ServiceNow by using the type value that was returned from LUIS.

In the event that LUIS doesn’t return any entities and can’t confidently predict what the user is requesting, we can send in the Category field blank. This will then land in ServiceNow as a general enquiry where a human will need to triage.

Overall, our logic app looks like the following:

Testing

Let’s now run a couple examples through and see what happens.
### Test 1
LUIS Input: My computer crashed
LUIS Output:

 {
    "entity": "computer",
    "type": "Hardware",
    "startIndex": 359,
    "endIndex": 366,
    "score": 0.9207772
  }

ServiceNow Ticket:

Outcome: This example worked as expected. We wanted to detect when someone had an issue with their computer that it was a Hardware problem and as a result, log the ticket correctly.

Test 2

LUIS Input: I would like to book some training
LUIS Output: No Entity Detected
ServiceNow Ticket:

Outcome: This worked as expected as well. LUIS couldn’t detect what “booking some training” meant so as a result a general inquiry was created. This is ok, what we could do now is head back into LUIS and train it some more so that when this type of request happens again, we have coverage for it.

We discussed how we can use intelligent technology to automate unstructured inputs. In our example, we took sending emails to a Service Desk, an event that happens all too often and historically has required people to triage. Now it is important to understand that the ‘machine’ isn’t perfect.