Power Virtual Agents (PVA) is a technology that provides a design surface for creating apps using a low-code or no-code development methodology. The designer enables the creation of apps to automate common business processes like a company-wide FAQ’s, handle HR questions with Bots, or friendly service desk automations. Several other scenarios can be developed within the confines of your company’s technology ecosystem. One recent addition to this technology is bringing PVA’s to Microsoft Teams, both as an execution environment as a well as a design surface. Microsoft’s project name for this is called “Project Oakdale.” My colleague Salman Mahmood covered this technology in his recent blog post here.
The following image is from the Teams interface-
The following is the design surface provided-
This post, and the next coming in a few weeks, will cover “skills” within the PVA Bot design surface and adding those “skills” for use and re-use in other Bots. I will not be covering the specifics of building a PVA Bot in detail, but you can find a good walkthrough at the following link- https://docs.microsoft.com/en-us/power-virtual-agents/authoring-fundamentals.
The idea behind PVA Bots is to create a dialog with the user around “topics” and “triggers” (words/word phrases) that initiate that dialog interactivity. Unlike traditional search-style information retrieval, Bots are intended to be conversational, not terse or query based. In more advanced Bots, this lends to the idea that Bots are more than just a search result. Bots can also intelligently surface information not explicitly requested or make associations within a large dataset. However, PVA Bots used for no/low-code development would not typically handle advanced scenarios, although you can go further in development. The following link discusses extending your PVA Bot with more advanced techniques- https://docs.microsoft.com/en-us/power-virtual-agents/advanced-fundamentals
One other aspect of Bots is the ability to perform “actions” beyond returning textual information. A PVA Bot can cause actions to happen as a result of a user’s dialog. These actions can take the form of calling Power Automate, for example. With actions, the Bots reach really has no limits as Power Automate can perform tasks such as manipulating SharePoint lists, calling REST API’s, and interacting with databases. This ability gives Bots and low-code developers a very powerful tool.
Moving Beyond Your First Bot
Provisioning your Bot with topics works well provided you keep a reasonably narrow focus on the Bots intended use. For example, an interactive FAQ on retirement planning is very different than inquiring about an employee skill or starting an action on a remote database. The idea is to separate concerns into individual Bots. This is exactly how PVA Bots are intended to work, you do not want to necessarily manually manage many topics and triggers over a wider area of concerns. Some topic automation is provided, but the actual area of expertise for your Bot should be well defined. The following links discusses a way to help manage topics- https://docs.microsoft.com/en-us/power-virtual-agents/advanced-create-topics-from-csi
This leads us into the topic of “Skills.” Skills are Bots (I refer to them as “Skill Bots”) that make themselves available to other Bots. Skills perform a specialized function for your Bot and live outside of your Bot. One example is, say, a school science curriculum. Students are asked to use a Bot as a technical resource. This Bot may cover several science topics where each topic has a unique set of sub-topics and actions the Bot performs. In this case, Skills may be bundled as separate Bots. Your task is to provide a single Bot entry point for the students rather than having them keep track of the various topical Bots created.
Here is the catch: Skill Bots cannot be created from PVA Bots. PVA Bots can consume external Skill Bots, but you cannot build a Skill from PVA Bots. PVA Bots have several other limitations as well. For example, a PVA Bots cannot use nicely formatted adaptive cards, directly call a REST service, or navigate to a page upon bot response. These are advanced capabilities. The following table illustrates how to think about the difference-
One way of creating Bots that can be included in other Bots is to ramp up with Microsoft Bot Framework. This is a “pro-developer” level of knowledge. The Bot Framework has been around for several years and involves coding Bots from the ground up. The biggest advantage to knowing Bot technology at this level is you are not limited to any design surface limitations, actions, presentation styles, topics, and flows. You are totally in charge. The cost of this level of expertise is that the ramp-up time is long, even for experienced programmers. The following links cover this topic-
The content of these links is out of scope for this and the next post in this series, but Microsoft does provide an alternative to the pro-developer path described here. In this final section, I will introduce the “Bot Framework Composer” and “Bot Framework Emulator”. The Bot Framework Composer has managed to provide a significant portion of capabilities only found in the Bot Framework itself. This means you can actually create a Skill Bot with many of the features only provided in the Bot Framework itself. That includes Cards, direct calls to external API, Luis, QnA, and many more. Once created, these Skill Bots can be “pulled in” to your PVA Bots as a separate skill and leverage all the capabilities you would expect in a more advanced Bot
The following image depicts the design surface provided.
In the next post for this series, I will walk you through creating a simple PVA Bot extended with a Skill Bot using the Bot Framework Composer. I will demonstrate features not found in current PVA Bots including adaptive cards, REST calls, and page redirection.
Check back soon for part two of this Project Oakdale series! If you have any questions or comments, please feel free to contact us today!