CRM Chat Bot: Part 4 – Deployment & Action!

In the previous part of this series, we have seen the sample implementation and how the code is running against a CRM Online instance. In this post I will show on how to deploy the chat bot to the supported channels.


As illustrated above, the built bot has the capability to be deployed to multiple channels leveraging the built-in capability of Bot Connector library.

Bot Registration

To deploy the bot, first we need to sign up to register the bot: (this requires a Windows Live ID to sign up). Once signed-up, you will be able to register the new Bot:


You will then be asked to setup the App ID and password. Please take note of this App ID and password, as this will be the one that we will use in the Web.Config.


Then update your web.config of the bot with the generated App Id and Password.


Now we are ready to deploy to Azure App Service. You need to make sure that your Visual Studio has the latest Azure SDK. To publish it, right click the bot project and click on Publish.


This will prompt the details for the Azure App Service deployment.BotAppService1.png

Continue to create, once the App Service has been created, it will show below screen:


Note: Take note the destination URL, this will be the bot endpoint. You will need this base URL  and  the API path”/api/messages” to be configured on the bot registration site.


Once the endpoint has been setup properly, you could verify and test the connectivity:


Channels Configuration

Congratulations, we are nearly there. The next step is to configure the channels. Skype and Web Chat are automatically configured by default. To add other channel it is really simple. Just follow the guide provided by Microsoft is sufficient.


Once it’s configured with the details, now here is the bot in action:


As I’ve configured it on different channels, the same Bot is working on different platforms, such as Slack and Skype.

Example on Slack:


Example on Skype:



Microsoft Bot Framework is relatively new for the community, however it has produced a great framework to built multi-channels conversational bot. Where the developers only need to developed the bot once and it can be deployed in many different channels rapidly.


The diagram above depicts the high level on how the bot application is deployed and work together as a solution.

I hope this post helps you to gain the understanding on the Bot Framework and how it can be integrated with Dynamics CRM and other Microsoft platforms.

This post is the end of the CRM Chat Bot series. There will be a spin-off post on a topic related to Luis Model that was used in this example. So, stay tuned🙂



CRM Chat Bot: Part 3 – Development Deep Dive + Integration To Dynamics CRM

In the part 2 of the series, we have discussed on the concept of how the Bot Framework library is used to assist us building conversational bot. As promised in the previous post, I’m going to share the source code on how the bot framework can be integrated with Dynamics CRM.

The Story

Now, to build a conversational bot, it will begin with the use case of the bot. In my example, I’m going to use an imaginary  car dealer with this simple “User Story” from Scrum principle: “As a customer, I want to be able chat and let the company know that I want to test drive a car, so that I can make an informed decision when I’m buying the car”.

The Implementation

In the previous post, we have discussed the concept of Dialog, Form Flow and Luis Dialog. Now in this post, I will show on how these concept can be applied.

In general I’m creating the TestDriveDetail class to contain the test drive request detail:

Notice that all classes that will be used in Bot Framework will need to be decorated with [Serializable].

And a simple helper class to create the record to CRM.

Now, I’ll give the example of the simple implementation with the 3 different techniques (Dialog, Form Flow and Luis Dialog).

Sample #1: Simple Dialog


The sample dialog is a series of prompt and at the end of the process it the store the information in CRM Online. Below is sample code of the Dialog, how the chain of prompts are created and at the end it is storing the record in CRM.

Sample #2: Form Flow


As you can see at the above screen, the form flow is automatically generate the questions with the pre-defined options. Below is the source code of Form Flow implementation:

To initiate the Form Flow from message controller:

Sample #3: Luis Dialog

Now, we have seen how Dialog and Form Flow is getting the simple conversation started. However, if you might notice, the bot can only understand predefined keywords or options. (In Dialog, it is hard-coded to find “Test Drive” and in FormFlow it is directly asking the detail).

To overcome this, Microsoft has come up with a really cool Language Understanding Intelligent Service, a.k.a LUIS. In this post, I’m not going to describe in detail on how to setup LUIS model (will do next time), but I would like to introducing its capability that is able to predict/interpret the intent of the user. For this sample, I’ve prepared the following LUIS model:


This model is configured to be able to interpret the intent of the user (Greeting, Test Drive, Ending Conversation, Brochure Request, None).


Now, below is the source code on how the Luis Dialog is built.

That’s all for the sample codes! I hope this helps. For the code repository, feel free to have a look at github repo:

Stay tuned for the next part of this series: Deployment.


CRM Chat Bot: Part 2 – Microsoft Bot Framework Development Concept

In the Part 1 of this series we have explored on how to configure the development environment and run the Bot Framework template to get the “Hello World” kind of reply from the Bot.

Now in this part, I would like to discuss about the development concept of Bot Framework. Behind the scene Bot Framework is an API that is encapsulated within Bot Connector library. The focus of the API itself is to provide a conversational context. Each conversation that come from the user is captured as “Activity”. “Activity” class is part of Bot Builder library. So, be careful not to mixed up with the other “Activity” class on Microsoft .Net framework or even from Dynamics CRM SDK. (Ref:

So far there are 6 activity types that the Bot Framework has:

ActivityType Interface Description
message IMessageActivity a simple communication between a user <-> bot
conversationUpdate IConversationUpdateActivity your bot was added to a conversation or other conversation metadata changed
contactRelationUpdate IContactRelationUpdateActivity The bot was added to or removed from a user’s contact list
typing ITypingActivity The user or bot on the other end of the conversation is typing
ping n/a an activity sent to test the security of a bot.
deleteUserData n/a A user has requested for the bot to delete any profile / user data


From the above activity types, “message” probably will be the most commonly used activity type.

Now, let’s drill down to the Activity class. The fundamental basic of Bot is to reply the message that is typed by the end user.

Now, let’s take a look at the code that is generated by the template to understand the basic of message reply from the Bot.


The highlighted part of the code above is the basic on how the Bot Framework is constructing the reply to the activity.

Ok, we might have the reply from the bot, but it is just the same reply all the time, it is not useful. Bot should be able to engage the user with something meaningful. So, to start a meaningful conversation there are some concepts that we can use: Dialog, FormFlow and Luis.

Note: In this post, I will cover just the high-level concept first and will deep dive with the code examples on the next post.

1.     Dialog

Dialog is the basic model of conversational process. Each Dialog in Bot Framework is encapsulated in a C# class that implements IDialog. The overview of Dialog provided by its documentation (

Dialogs model a conversational process, where the exchange of messages between bot and user is the primary channel for interaction with the outside world. Each dialog is an abstraction that encapsulates its own state in a C# class that implements IDialog. Dialogs can be composed with other dialogs to maximize reuse, and a dialog context maintains a stack of dialogs active in the conversation. A conversation composed of dialogs is portable across machines to make it possible to scale a bot implementation. This conversation state (the stack of active dialogs and each dialog’s state) is stored in the state service provided by the Bot Connector service, making the bot implementation stateless between requests. (Much like a web application that does not store session state in the web server’s memory.)

In short, Dialog is the simplest conversation building block for Bot to communicate/reply. Dialog can be meaningful with its Chain method. To make it simple analogy, Chain can be illustrated as a series of command prompt dialog that will handle the reply from the user.

2.        Form Flow

Dialog is good for a starter piece of conversation. However, it can be really tedious job to build the Dialog that might have some aspects of ambiguity. Form Flow, as the name suggests, is based on the idea of a form, where there is a collection of fields to be captured throughout the conversation. Form Flow share the same principle as Dialog, where a “Form” is built through a C# class. Where it is using basic C# data types, such as: Integral, Floating Point, String, DateTime, Enum and List of Enum.

3.        LUIS

Now, with Dialog and Form Flow, the bot can handle basic conversations, however the bot itself will only understand the command based on the pattern of the message. With LUIS (Language Understanding Intelligent Service) from Microsoft, the Bot can be smarter to predict what is the intent of the user. To use LUIS, in code, it will be similar to the normal Dialog class, but we will inherit LuisDialog instead of the IDialog class.

A comparison of normal Dialog vs LUIS Dialog is applicable when we need to handle a conversation that initiates a car interest. With the normal Dialog, we need to put some hard-coded If-Else conditions and regex patterns to predict what is the user wants. But with LUIS, it will provide an output of the possible intents based on the conversation reply analysis.

Part 2 – Conclusion

So, I hope this post helps you to get the basic understanding of Microsoft Bot Framework and get the understanding of the toolset that the SDK provides. Stay tuned for the Part 3 – Development Deep Dive + Integration Through CRM API.

CRM Chat Bot: Part 1 – Getting Started with Microsoft Bot Framework

Microsoft quite recently announced the Microsoft Bot Framework on Build Conference 2016. Below is the overview of the vision of Bot Framework from Microsoft:

The Microsoft Bot Framework provides everything you need to build and connect your bots to your users wherever they converse – from SMS to Office 365 mail to Slack and more… It’s your bot, wherever your users are talking. Learn how to use the Bot Framework to build a bot with your own existing code, use the Bot Builder to generate conversational dialogs from scratch, and more to give your bot skills with natural language processing and deep learning technology. Walk away with tools to build a great bot that can connect with users, wherever they are.

I’ve spent a few months reading and researching on the new Microsoft Bot Framework and I hope with this blog post series I could share and introduce how Microsoft Bot Framework to work together with Dynamics CRM.

Getting Started

Microsoft Bot Framework supports Node.js, .NET and REST Bot Builder SDK. In my posts, I will use .NET based bot, as this is the most common platform that CRM developers use to reduce the learning curve with the Bot Framework.

To start building the bot, we need to set the development environment. Below is my development environment setup:

  • Visual Studio 2015 Update 3 (latest update)
  • Bot Builder SDK (download links are here)
  • Visual Studio C# template (download here)
    • To install, extract the downloaded template and copy it to Visual Studio Project Template. Typically it is located on: “Documents\Visual Studio 2015\Templates\ProjectTemplates\Visual C#”
  • Bot Framework Emulator (download here)
  • Microsoft Account
  • Microsoft Azure subscription (trial license should do)

Once the environment has been configured, you should be able to see the new project template to be available in Visual Studio:


Let the Journey Begins…

Now let’s create a new bot application. This will give you the following project structure:


Then we need to install these NuGet packages:

If your environment setup is successfully installed, you would be able to see a page similar to below on build:


Bot Emulator

We will use the Bot Emulator to simulate the conversation. Take note of the URL of the page before and enter it in Bot URL.


You now will see that the bot is replying. Congratulations, you have your first reply from your bot🙂 

Lesson Learned/Troubleshooting

  1. During the research, I encountered a few differences on the sample code. Some of them used “Message” and some have “Activity”. Apparently, it is part of the update on Bot Framework V3 ( that Microsoft changed the usage of Message to Activity.
  2. Another difference in Bot Framework V3 is that you no longer need Microsoft.Bot.Connector package, Microsoft.Bot.Builder is now include the Microsoft.Bot.Connector assemblies.
  3. Use .Net Framework 4.6 and above to develop Bot. I used 4.5.2 (as this is the current supported framework for Dynamics CRM), this will resulting the installation of Microsoft.Bot.Builder package to fail:

Install-Package : Could not install package ‘Microsoft.Bot.Builder 3.2.0’. You are trying to install this package into

a project that targets ‘.NETFramework,Version=v4.5.2’, but the package does not contain any assembly references or

content files that are compatible with that framework. For more information, contact the package author.

At line:1 char:1

+ Install-Package Microsoft.Bot.Builder

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception

    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand


Stay tuned for the Part 2: Microsoft Bot Framework Development Concept!

CRM Ideas, Let your ideas listened

Microsoft just announced CRM Ideas portal:

Previously the way we submit our feedback/ideas is through Microsoft Connect: However it seems this site might not be known well and the user experience on that site is not as good as the new portal.

The new portal seems to be based on AdxStudio, from the profile management perspective:idea_portal_profile.png

The user interface of the idea portal is also looks nicer compared to the previous portal:


So, what are you waiting for, submit your idea now!

Note: Before you post, please read this posting guideline:

Ribbon Workbench 2016 beta on XrmToolBox

I just recently re-opened my XrmToolBox to do some Sitemap modification and found out some new plugins are available on the XrmToolBox plugin store. One of it is Ribbon Workbench 2016 beta by Scott Durow.

My first test run on my solution showing that the 2016 version is much quicker compared to the Silverlight-based version that is running on CRM web app.


Looking forward for the final version. It will be awesome!


Gotcha Working with Dynamics CRM Web API: Grammar..

Microsoft has suggested developers to start using the new Web API to develop new custom development. As they are planning to deprecate the 2011 endpoints sometime after CRM version 9 (We are on version 8 now!). Ref:

So, I’ve embraced the Web API in my new projects for javascript codes. Typically I would use CRM Rest Builder by Jason Lattimer to build Web API request in Javascript.

I found out it is quite interesting on one of my custom entity, let’s call it “cust_selectionmatrix”. I tried to build the query using the tool, but I won’t generate the query as expected. Then I tried to look at Microsoft examples around the Web API query. Most of them are appending “s” against the entity name. E.g: for account: /api/data/v8.0/accountand for contact: /api/data/v8.0/contacts.

So my first trial is just adding s at the end of my custom entity: /api/data/v8.0/cust_selectionmatrixs. However, I’ve got a weird error:

"Resource not found for the segment 'cust_selectionmatrixs'."

Then after I tried to find the list of entity for Web API using  <CRM Server URL>/api/data/v8.0/I found out that my entity is named: “cust_selectionmatrixes” in the Web API. I reckon this is how CRM is implementing “English”. So, if your entity ends with: ‑s, ‑sh, ‑ch, ‑x, or ‑z. Just append ‘es‘ to your entity name to work with the Web API.



Then.. There was an awkward moment when I have an entity named “cust_settings” and it is translated as “cust_settingses“… 15jkjv.jpg