Welcome to the third post in my series focused on providing a set of revision notes for the PL-400: Microsoft Power Platform Developer exam. In last week’s post, we provided an overview of some of the core features and functionality to consider when designing solution components within the Power Platform. Today, we’re going to finish up our review of the first area of the exam - Create a technical design - by looking at the final set of topics in this section, namely:

Describe Power Platform extensibility points

• describe Power Virtual Agents extensibility points including Bot Framework skills and Power Automate flows
• describe Power BI extensibility points including Power BI APIs, custom visuals, and embedding Power BI apps in websites and other applications
• describe Power Apps portal extensibility points including CRUD APIs and custom styling

As we’ve alluded to so far in previous posts, the great advantage of the Power Platform is that you have a collection of applications that have powerful native capabilities, buttressed by strong extensibility points - both in themselves and into other tools. The purpose of today’s post will be to introduce these concepts at a high-level, without necessarily diving into too much detail on each. This is primarily due to the comparatively low weighting of these topics in the exam overall. Let’s get started! 😀

As with all posts in this series, the aim is to provide a broad outline of the core areas to keep in mind when tackling the exam, linked to appropriate resources for more focused study. Ideally, your revision should involve a high degree of hands-on testing and familiarity working with the platform if you want to do well in this exam.

Bot Framework Skills

With the proliferation of AI chatbots across the web, there are likely situations where someone has constructed an existing scenario to meet your needs. Specifically, it could be that your organisation has previously worked with the Bot Framework and Azure Bot Service, and you have several such bots that you would like to leverage from within the Power Platform. Or it could be that you want to experiment with one of the several, available Bot Framework Solution examples that Microsoft has developed, which can help address existing scenarios or inspire you to build out one of your own. For all of these situations, Bot Framework Skills allows you to blend in a bespoke developed solution so that you can leverage it from within Power Virtual Agents, much in the same way you would with any other action step. There are a couple of things you need to do within Power Virtual Agents to get started with Bot Framework Skills:

1. First, set up your bot within Power Virtual Agents.
2. If leveraging a custom authored Bot, ensure you’ve deployed this out onto Microsoft Azure, either via the web interface or using CLI tools.
3. Register the Bot Framework Skills within Power Virtual Agents.
4. Navigate to your relevant Topic within Power Virtual Agents and then add a Call an action step that references your newly deployed Bot Framework Skill.

It’s as simple as that, from a configuration standpoint at least. Typically, the process for authoring a Bot will be far more involved and require detailed study to understand fully. But we, thankfully, don’t need to worry about this for the PL-400 exam. 😅

Using Power Automate Flows with Power Virtual Agents

At the start of this series, we referred to a specific type of integration between Power Virtual Agents and Power Automate:

• Call a Power Automate flow from a Power Virtual Agent, to return information from an on-premise Oracle database.

This type of action is straightforward to incorporate within Power Virtual Agents, by merely calling a new action and creating a Flow that is then linked back to your topic. What you then do with this Flow is entirely up to you. To help you get the most out of this type of extension, you can configure various input/output parameters to communicate data between Power Automate and Power Virtual Agent. You will often need to ensure that you create your Flow, from scratch, within Power Virtual Agent; at the time of writing this post, adding an existing Flow into Power Virtual Agents can cause communication issues between both systems. Also, keep in mind that any Flow you create will reside within the Default Solution once made. Be sure to follow the correct steps to get this added into a Solution, to ensure portability and best practice for your work.

Power BI API Overview

Time for a gear change as we jump across to Power BI now! Generally, you don’t need to concern yourself too much with detailed information regarding this fantastic business intelligence tool for the exam. However, one of the core concepts that you need to grapple is the capabilities on offer as part of the Power BI REST API. To summarise, the key capabilities on offer here are all designed to assist in managing, configuring and, in particular, working with your Power BI solution when embedding it within external applications; more on this shortly. Much like any Microsoft Software as a Service (SaaS) product, to start working with the API, you’ll need to register an Azure Active Directory application and then use this to generate an access token into the service. From there, you can start to perform operations such as:

• Adding rows to an existing Power BI dataset
• Adding, removing or modifying any existing data sources bound to an on-premise gateway.
• Listing details about various elements within your Power BI tenant, such as dashboards, dataflows or apps

Further discussion of the API is beyond the scope of PL-400. Familiarise yourself with the high-level capabilities offered and don’t spend too much time brushing up on each operation available.

Custom Visuals in Power BI

If you’ve worked with Power BI before, you will be familiar with the various standard visualisation types on offer, such as gauges, area and funnel charts. However, there will be certain situations where you need to express your data differently, and the out of the box visuals just won’t cut it. For when this happens, developers can turn to one of two solutions to build custom visualisations. The first is using Node.js and the pbiviz tool. This route offers the most flexibility, but does involve several pre-requisites and requires you to have good knowledge of TypeScript to build out. Secondly, you can use the R programming language, via the R script visual type. Using R simplifies some of the setup involved to build out your custom visual but still requires R installed on your local machine. For situations where you would like external users or organisations to install your visualisation, you can look to get it certified and made available as part of AppSource. Microsoft will only accommodate Node.js visuals as part of this. Custom visuals can help us in our general objective towards ensuring re-usability for our solutions and, much like everything else, should only be explored if no existing visuals, either from Microsoft or AppSource, can meet your requirements.

Embedding Options in Power BI

As alluded to earlier, the Power BI API becomes particularly relevant in the context of embedding your Power BI solution within an external system. There are typically two approaches to achieving this:

• Anyone with a Power BI professional subscription can look to embed a Power BI Report within various internal business systems. Users will typically need to authenticate discreetly into your Power BI tenant as part of this and require permissions to any underlying report or dataset to interact with the content. There are also options available to embed a report within a public website, but this is generally discouraged unless the underlying data is suitable for public consumption. In short, this route provides the most straightforward and cost-efficient path open when embedding Power BI into other systems.
• For situations where performance considerations are paramount, and you need fine-tuned control over the embedding experience, Power BI Embedded and it’s related components - including the Power BI API - come into the equation. Using this Azure-based service, developers can almost invisibly integrate Power Bi visualisations within their core application, thereby allowing them to focus attention towards their apps core functionality instead of building a reporting suite from scratch. Power BI Embedded is a powerful tool, but requires careful consideration from an architecture standpoint and can also introduce significantly more cost into your solution than the previous option.

Before we move on, let’s circle back now to why the API and Power BI embedded are so closely intertwined. One of the core requirements for a Power BI Embedded based solution is that your content must reside within a Power BI workspace. The developer building the report must then have an assigned license to deploy this out. As such, we must route any operations we perform to retrieve Power BI Embedded content through the Power BI REST API. You can follow through the available tutorial from Microsoft to understand how this works in practice and the types of core API operations that you’d need to perform as part of this. Having a general awareness of how you can utilise Power BI in this fashion is incredibly useful as part of your daily work with the Power Platform. Still, it should only be of minimum focus as part of your revision for PL-400.

Power Apps Portal API

As we round things off in today’s post, it’s time to take a deep dive look at Power Apps portals, the third type of Power App that allows us to surface out our Microsoft Dataverse data for external users to work with our core business data. This product has been around for several years, under different names. A traditional limitation that developers have found with them is the inability to straightforwardly access common API operations that are available as part of the Microsoft Dataverse Web API. Recognising this need, Microsoft is in the process of releasing a dedicated API that we can access through a Power App portal. The functionality currently on offer allows developers to perform CRUD operations targeting Microsoft Dataverse, alongside the ability to perform entity-relationship associations and disassociations. Developers would construct these as standard HTTP requests, which we can then fire off at various points within a portal. Developers must ensure that the portal’s site settings are modified to enable the table and the list of columns that will ultimately be consumed by the API. A portal administrator can also enforce permissions via table permission configurations that already exist. To summarise, the new functionality on offer opens the door for developers to perform complex Microsoft Dataverse operations via code, for situations where other out of the box solutions will not suffice.

Now, similar to what we highlighted with Canvas Power App Components in last week’s post, all of this functionality is currently in public preview. Microsoft will not typically assess candidates on unreleased functionality, so it is unlikely you will be evaluated on this feature now. Nevertheless, you should continue to check the relevant Microsoft Docs documentation to confirm whether Microsoft has released this into general availability. It will become prudent to spend some more time analysing the capabilities on offer here at this juncture.

Custom Styling within a Power App Portal

Styling within a Power App portal occurs via the use of a theme - either an out of the box one provided by Microsoft or one you’ve developed yourself using custom CSS files and Bootstrap. The latter option will typically give you the most control, thereby ensuring the enforceability of an organisation’s branding and styling requirements within a portal. It’s worth noting that a single site on a portal is limited to only a single theme. For situations where you may need to fine-tune a specific page’s styling, developers can instead turn to Web Templates and the Liquid templating language to meet this requirement. As well as supporting the ability to render data from the application, it’s also possible to apply HTML, CSS or JavaScript snippets, to control the look and feel of individual pages. Using a mixture of these two features, you can start to customise a portal to suit multiple scenarios with ease. In fact, we’ve only really touched the surface of what Portals are ultimately capable of. Feel free to explore them further at your leisure but, for PL-400, you can be satisfied that these are the main concepts to be aware of concerning portal styling.

And that brings us to the end of today’s post. So far, we’ve covered a lot of detailed theory, which is what this area of the exam expects. I hope that the content covered so far has been easy to grasp and contextualised accordingly. In next week’s post, you may be pleased to hear that we’ll start diving into some “hands-on” content, as we look at how to work with solutions in Microsoft Dataverse.