City of Wisdom – The Proactive Bot

I am incredibly excited to show how proactive bot concept works in this post. To be honest, I just wanted to do a single blog about the “Proactive Bot” instead of a blog series. But one wouldn’t be able to appreciate it without understanding the context of the bot creation and the underlying infrastructure, some of which was covered in my previous posts.

In the previous post, we saw how to get the information from citizen and store it as a service request in Dynamics 365.

Let’s imagine that a field staff is deployed onsite and the service request is now resolved and subsequently, the status is changed to “Resolved” in Dynamics 365. Wouldn’t it be nice to send a quick update on the issue closure to the citizen who reported it?

That’s the agenda for this post.

I warn you! There are a few moving parts involved to get this done. But trust me, it is going to be super exciting!

Buckle up! Let’s get started.

As usual, before jumping right into our solution, let’s take a step back and destruct the concept.

What is Proactive Bot?

So far, we have seen a bot that responds to user’s message and builds up a conversation. Proactive Bot is a bot that may send an information to the user that is not directly related to the user’s most recent message.

This MS documentation sets the stage about the proactive bot. In this post, we are going to use the “Proactive bot” concept in order to send the resolution status to the citizen.

Here is the overall architecture for the visio

Let’s understand the nomenclature:

Bot Service – This is our bot application which has the code to process the message to be sent to citizen.

Azure Function – Azure Function is a Azure’s server-less service that enables you to run code without having to explicitly provision or manage infrastructure in response to an event.

Azure Queue – This is Azure’s storage that gives you asynchronous message queuing for communication between various application components. In short, this is where we store our messages back and forth between the bot and the citizen.

Direct Line endpoint – Direct Line endpoint in MS Bot Framework provides a flexibility that allows clients to directly communicate with the bot. We use this endpoint in order to pass the message from Azure Function to our bot.


Our key idea is to message the user about the service request that they previously submitted is resolved. But the bot is stateless, how are we going to send the message to the user?

hmm.. Let’s say you are having a conversation with your friend. What if we have an ID to describe that specific conversation. If your friend wants to reply back, he/she will use the same conversation ID to reply back, so that you can easily identify the context of the conversation. If you observe keenly, conversation id is the key.

This is the concept we are going to borrow in this post.

If you have reviewed the previous post, we store the bot channel profile information which describes the channel data through the citizen previously interacted with the bot. The channel data typically contains user id, channel name (Facebook), conversation id (the id that uniquely identifies the conversation). Bingo! we have our Conversation Id.

When the service request’s status is changed to “Resolved”, Flow is triggered which will retrieve the data (essentially the Service Request data from the Service Request entity and recipient data from the associated Bot Channel Profile entity) from D365 and compose a message that contains everything that our bot needs to send the message to citizen. Finally, the Flow will put the message in the Azure Storage Queue.

Then, Azure Function will read the message from the Queue and passes the message to our bot through the Direct Line endpoint.

Finally, the message is in Bot’s court.

As you would have guessed, the Bot parses the message and extracts the actual data and finally, Bot constructs a response object and shoots the message directly to the appropriate citizen.

Alright. Now, let’s dig a little deeper on each of the statements above.

Dynamics 365

From our previous blogs, we setup the Service Request and Bot Channel Profile entity. These entities are prerequisites to proceed with the steps drafted below.

Azure Storage Queue

If you haven’t created a Storage Queue before, follow this documentation to create an Azure Storage Queue. MS Flow requires the name of the Azure Queue in order to put the message in.

The Resource group that you use to create the Azure Storage is later required in order to create the Azure Function.

Microsoft Flow

Create a MS Flow that will get triggered whenever the status request is updated in D365. If the status is “Resolved”, then compose a JSON object that contains all the details that our bot needs to send the message to the citizen and put in Azure Queue.

Here is a sample JSON object that the MS Flow composes to send to the Azure Queue.

"alert": "Your request has been resolved",
"channelid": "facebook",
"conversationid": "182503-2065",
"fromid": "182503",
"fromname": "Dhinakaran Gajavarathan",
"recipientid": "2065",
"recipientname": "FBMessengerChannel",
"serviceurl": ""

I have exported the Flow and uploaded in the github project. – When you import (refer this documentation if you have not imported a flow previously) the Flow, ensure to connect to your Dynamics 365 instance and Azure Storage Queue.

Azure Function

Azure Function will pickup the message from the storage queue and sends it to bot.

So, we need an Azure Function that triggers on the “Azure Queue Storage” and Outputs the message to “Bot Framework”.

I have created an azure function and exported it as a Visual Studio solution for you to publish it to your Azure subscription.

Open the Azure function project in the Visual Studio and open the run.csx file.

public class BotMessage
public string Message { get; set; }
public static BotMessage Run(string queueMessage, out BotMessage botMessage, TraceWriter log)
botMessage = new BotMessage
Message = queueMessage
log.Info($"Message Processed: {queueMessage}");
return botMessage;

view raw


hosted with ❤ by GitHub

This is all the code we have in our Azure function. When the function gets triggered, it receives the message from the queue and outputs it (to the bot connector through directline endpoint).

Open “function.json” file.

"botId": "",  //add the bot ID here
"secret": "",  //add the bot's directline secret here

Against the botid key, add your specific bot id.

To obtain your bot id, go to your Bot channel that you setup previously and go to Settings and copy the “Microsoft App ID”.

find Bot ID.jpg

Against the “secret”, you need to specify the bot’s directline secret.

Please refer to this documentation in order to setup the bot’s directline channel and to obtain the direct line secret and update function.json.

Publish Azure Function

  1. Right click your project and click on Publish. Ensure to click “Create New”.

publish 1.PNG

2. Ensure to choose the same Resource Group that you selected in order to create the Azure Storage.

Create Azure Function.jpg

Publish Azure Function.PNG

3. Once published, navigate to the Function app in your Azure Subscription.

Show Directline edit 1.PNG

4. Click on “Application Settings”

Show Directline edit 2.PNG

5. Create a new Setting

App Setting Name: AzureWebJobsBotFrameworkDirectLineSecret

Value: Paste the Bot’s Direct line secret that you obtained earlier.

Show Directline edit 5.jpg

Now, your Azure Function is ready to get triggered when the queue receives a message.

Bot Application

You can find the updated Bot source code in github.

When we receive the message from Azure Function through the Directline endpoint, we parse the message to extract the channel and conversation data and send a response to the citizen.

/// <summary>
/// The bot is obviously stateless. When we get the message from D365, we need to parse the data to find out which citizen should receive what message on which channel.
/// </summary>
/// <param name="activity"></param>
private void CommunicateMessageToUser(Activity activity)
var message = JsonConvert.DeserializeObject<QueueMessage>(((JObject)activity.Value).GetValue("Message").ToString());
//Conversation ID is generally the key in order to reply to the same conversation in the channel.
var recipient = new ChannelAccount(message.RecipientID, message.RecipientName);
var from = new ChannelAccount(message.FromID, message.FromName);
//These couple of lines are important to estabilish the trust that we are authorized to send the message in this channel.
var connector = new ConnectorClient(new Uri(message.ServiceURL), new MicrosoftAppCredentials(ApiKey, ApiEndpoint));
var alertMessage = Activity.CreateMessageActivity();
if (!string.IsNullOrEmpty(message.ConversationID) && !string.IsNullOrEmpty(message.ChannelID))
alertMessage.ChannelId = message.ChannelID;
message.ConversationID = (connector.Conversations.CreateDirectConversationAsync(from, recipient)).Id.ToString();
//I know I am flipping the "recipient" and "from" objects. The reason is that when we originally received the message from the citizen,
//the citizen related attributes is present in the from object and bot related attributes are present in the recipient object and it makes sense as,
//the citizen sends the message and the bot receives it. But, now the table has turned. The Bot sends the message and the citizen receives it,
// which is why i flip it.
alertMessage.Recipient = from;
alertMessage.From = recipient;
alertMessage.Conversation = new ConversationAccount(id: message.ConversationID);
alertMessage.Text = message.Alert;
alertMessage.Locale = "en-Us";
//Once the connection is established to the channel and the conversation, the bot can reply with the text.


Let’s see our work in action.

When you change the status of the service request record in D365, the bot will send the message to the citizen on Facebook Messenger.

Dynamics 365 Status change.gif


Messenger Service Request.gif


I think the power and sophistication of the bots will not be harvested just only by improving up on the bot SDK, but by constructing the environment for the bot to thrive, and that environment is simply called as Azure.

So far, you have seen we use a number of azure services along with the Bot SDK to make it powerful by the day and it is very encouraging to know that Microsoft organically improves the environment while continuing to improve the bot SDK.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s