Using Power Virtual Agent Bots with Microsoft Portal

Microsoft's new Power Virtual Agents is a SaaS service allowing non-developers to create complex conversational bots which can be used in many channels. 

In this example, I'll explore how a chatbot may provide another customer interaction option for a Microsoft Portal built to support a Grant Management system. This bot will allow a Portal user to use chat interface to learn about the status of their grant application instead of having to navigate standard Portal menus.

After creating and naming your bot, the Power Virtual Agent designer presents options to customize and extend the new bot created from the template.

The minimum bot configuration revolves around building and configuring Entities and Topics that together define the Virtual Agent. The template used for the bot creation includes several topics and entities which can be used to learn about bot authoring options.

The Entities here are custom data types that are used to both present choices for our users, and also to convert end user's conversational entries into a typed information for further processing. For example, one of the pre-built entities is age:

I've created a new Entity called 'Grant Management Terms' which I'll use to query user about the target of their inquest.

Authoring a Power Virtual Agent Bot is all about building and configuring Topics. Each bot might include multiple topics, and a topic represents a conversational scenario, with trigger phrases that uses natural language processing to map a user's initial entry to a specific topic, and a set of choices within a topic to guide the conversation. For my Grant Management-themed bot, I want to capture user's intent (finding about the status of their grant, application, payment request etc.), collect relevant record number from the user, query the backend system for user's information and reply with the status.

To start building a topic, enter its name and enter all trigger phrases relevant to this conversation:

After configuring topic's triggers, click on on 'Go to authoring canvas' to open the topic designer. Within a conversation, you can show a message, ask a question (and collect user's response in a variable), call an action, end the conversation and go to another topic.

This latter option allows you to build a rich system of chatbots where each conversation is built to support just one theme, and the ability to pass conversation along to another topic provides open-ended design environment that can be enhanced and enriched without necessarily modifying already implemented topics.

In our bot, we first ask the user if they already have the number of the record (grant, application, etc.) they are asking about via a Question node. Than a Condition node will route the conversation depending on the response.

If the user says 'I don't know', we display a message, and hand it off to a live agent:

Otherwise, we use a Question node to collect the record ID and store it as RecordId variable, and another Question node to collect the record type (using Grant Entities type and RecordType variable).

The next step is to actually retrieve the data. For that, we add an Action node. Actions are what makes bots truly powerful by allowing them to call Microsoft Power Automate flow. At the moment, Action's inputs and outputs are limited to Numbers, Strings and Booleans only. Within our flow, we will use RecordId and RecordType variables to query our backend Dynamics 365 (CDS) endpoint and return a string that represents the status information that user would like to see.

 The flow receives bot's input in a JSON fragment, initializes recordstatus return value, and uses Condition to execute an odata query against the CDS connection based on what type of record user in interested in and using RecordId as a filtering parameter.

If odata query returns data, the recordstatus variable is formatted with the Status and dollar amounts. This will be a response send to the chatbot.

Once the flow returns the value to the bot, we'll show the response to the user and ask them if their query is answered. If they are happy, we end the conversation (using Redirect to the 'Thank you' topic). If not, we will transfer the chat to the agent.

Once bot is tested and debugged, we publish the bot. Publishing interface gives us multiple channels to integrate the bot within our systems (Facebook, Teams, Skype, Slack, mobile apps, custom websites, etc.). 

For this example, the bot is integrated in a Portal using embedded HTML:

<!DOCTYPE html>
<html>
  <body>
    <iframe src="https://powerva.microsoft.com/webchat/bots/0000000000000000000000" frameborder="0" style="width: 100%; height: 100%;">
    </iframe>
  </body>
</html>

Our Portal user can skip having to navigate traditional menu system and instead rely on chat window to get all their data they need.

Power Virtual Agents bots support authentication (using oauth2) directly within a conversation, which means you can fully enable protected conversation within the bot.

One final note is on extending Power Virtual Agents bots using Azure Bot Framework. Azure Bot Service is an open-source toolkit to build chat bots using AI services and natural language processing. If your organization already invested in Azure Bot Framework, you can extend your Power Virtual Agents bots using Azure Bot Framework Skills which allows you to "convert bots to a Skill and embed the Skill within a Power Virtual Agents bot."