Exam MB-400 Revision Notes: Introduction to Power Apps Component Framework (PCF) Controls

Welcome to post number nine in my series focused on providing a set of revision notes for the MB-400: Microsoft Power Apps + Dynamics 365 Developer exam. In last week’s post, we took a look at how JavaScript can be used to extend model-driven app forms. Client-side scripting is not the only potential usage case to trigger custom logic on a form or even override how default controls behave. Developers can implement Power Apps Component Framework (PCF) controls to completely alter how fields, views or other form-based objects operate. And, because they leverage modern web tools/languages, it is easy peasy to get a PCF control deployed out into the application. This feature is the focus of the next exam area we will look at in today’s post, with the expectation that candidates must demonstrate knowledge of the following subjects:

Create a PowerApps Component Framework (PCF) component

initialize a new PCF component

configure a PCF component manifest

implement the component interfaces

package, deploy, and consume the component

use Web API device capabilities and other component framework services

The development technologies involved as part of PCF components differ significantly from the areas that traditional Dynamics CRM developers will likely know. Therefore, let’s jump in to review this in further detail and, similar to last week’s post, focus on demonstrating how to deploy a simple PCF control out into the platform.

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. Your revision should, ideally, involve a high degree of hands-on testing and familiarity in working with the platform if you want to do well in this exam. I would also recommend that you have a good understanding of JavaScript, HTML/CSS, PowerShell, and working with Visual Studio before you attempt any of the examples provided in this post.

PCF Controls Overview

Stepping back into the world of Dynamics CRM for a few seconds, and we can see that our options for modifying the out of the box forms (now a central component as part of model-driven apps) are somewhat limited. Although developers have a high degree of control over the general layout of a form, our ability to modify how a text field is displayed remains virtually non-existent. Instead, developers would have to revert to building out HTML Web Resource files and then embedding these within a form instead. No doubt, alongside this, there would be a whole heap of JavaScript interacting with the applications Web API to provide the illusion of a custom interface. And while it is still possible to implement solutions of this nature, it’s interesting to note that this entire subject does not even get a single mention as part of the MB-400 exam specification. I believe this should tell you all you need to know and also the potential direction for this feature in future.

To help address the traditional needs of Web Resources and, additionally, allow us to overhaul the appearance within model-driven Power Apps completely, Power Apps Component Framework (PCF) controls are now here and ready to be used. They were introduced relatively recently and are currently in general availability for model-driven Power Apps. Because they take advantage of a whole heap of existing tools, developers can quickly bundle together re-usable custom components and deploy them multiple times across a model-driven app. These can not only alter the behaviour of the elements described earlier (fields & views), but also support additional capabilities, such as the ability to access the applications Web API. Some of the advantages they have over traditional Web Resources include:

The ability to bundle all aspects of your project together into a single solution file.
Because the application renders custom controls at the same time as the form itself, users get a completely seamless experience when using a model-driven app.
They are developed using modern web technologies, such as NPM, Node.js and TypeScript.
(Eventual) support for all types of Power Apps, both model and canvas.

Now, PCF controls are great but are not necessarily the most accessible tool to implement. Developers should evaluate the requirements of the overall solution and, where possible, guide an organisation towards introducing a canvas Power App instead, if that meets the requirements. To best illustrate how to make this decision, let’s consider the following two scenarios:

The organisation requires a highly tailored area within the Account form to create new Contact’s that will then be related to the parent record: Given there are numerous controls to implement, an embedded canvas app is the most straightforward solution here.
You’re managing a multi-lingual instance and need to ensure that all controls display in the user’s chosen language: Although this is possible to do via a canvas app, a PCF control is a more logical approach, given it can hook into the applications localisation settings.
The organisation has an existing Node.js/Angular web component on their website that they wish to replicate across into Dynamics 365: In this situation, a PCF control makes logical sense, as we can straightforwardly port this across to the application with minimal effort.
Your solution needs to immediately trigger and return feedback from actions triggered via Power Automate flows: As it stands, only canvas apps support this capability.

A good Dynamics 365 / Power Platform can build out a PCF control without issue; the sign of an excellent developer is identifying the appropriate usage cases for them, and in not necessarily resorting to them as a first-preference solution, if others can fit the gap.

Technology Areas Involved

PCF controls are an anomaly, to a degree, when you start looking at the technology areas that make them up. I would forgive you for assuming that they rely solely on .NET focused programming languages. Instead, they utilise some more recently developed languages targeted towards rapid web development. This circumstance can be potential blocker when learning about PCF controls for the first time, but it is a hump that is worth surmounting. The below list covers all of the languages and tools that help bring PCF controls together. It is impossible to provide a detailed overview of the inner workings of each of these as part of a single blog post, so I encourage you to perform separate revision in these areas; what follows, therefore, is a basic overview:

HTML: HyperText Markup Language (HTML) makes up everything to do with the web - including the very page you are reading now. It provides a structured, open standard, that bears some similarities to eXtensible Markup Language (XML). It will typically make use of other components, such as CSS or JavaScript, to provide enhanced styling or functional capabilities to an individual web page. From a PCF perspective, you would reference and work with common HTML constructs, such as divs, inputs and options, when building out your components.
CSS: Whereas HTML can be best thought as the “nuts and bolts” of the internet, Cascading Style Sheets (CSS) is the bit that makes it all look pretty and beautiful. Conforming to a JavaScript Object Notation (JSON) like structure, it allows you to apply a variety of different style rules to individual components that get loaded onto a webpage. For example, you can define whether a button changes colour when a user hovers their mouse over a control. CSS is used within PCF controls to help style and make your controls “pretty” for users within the application and may be necessary depending on your requirements. For example, you might need to ensure that your component mirrors an organisations branding guidelines.
TypeScript: TypeScript is an open-source language developed by Microsoft, with a lot of similarities to JavaScript. The main benefit it provides, hinted at by its name, is that it is a strongly typed language. This means it has full Intellisense support within Visual Studio/Visual Studio Code, allowing you to identify and fix issues quicker. From a compiler standpoint, all code written ultimately executes as JavaScript on a webpage. All of the logic and core functionality of a PCF control will be contained within one or several different TypeScript files.
NPM: Node Package Manager (NPM) is used within PCF controls to retrieve common, pre-built libraries/packages of functionality so that you do not necessarily have to reinvent the wheel when developing your code component for the first time. For example, rather than building a calendar control from scratch, you could instead use FullCalendar by downloading its appropriate NPM packages and then referencing the components you need within TypeScript.

A traditional Dynamics CRM Developer will perhaps be most familiar with the first two languages on this list. It is, therefore, essential to spend some time learning about TypeScript and NPM, to ensure that you can effectively build out a practical PCF component. Thankfully, TypeScript is very similar to JavaScript - another language that developers will need to know well for this exam - so I believe developers of this inclination will have little difficulty making the jump across to TypeScript.

Development Pre-Requisites

Before you can start writing a single line of code, you need to ensure you have ticked a few boxes on your machine:

You must have either NPM or Node.js installed on your computer. I recommend using NPM, as this includes Node.js as standard. During installation, be sure to tick the option to download additional tools, one of which installs Visual Studio 2017 Build Tools. After this has installed, be sure to go into the Visual Studio 2017 installer and add on the individual component NuGet targets & Build Tasks, an additional pre-requisite.
You must also have the .NET Framework 4.6.2 Developer Pack installed on your machine.
Finally, a specific CLI for developing PCF controls must be installed. The CLI will provide a range of commands to build, test and deploy your components as you build them out.

Further details on all these setup steps can be found on the Microsoft Docs website.

You must also make an important decision regarding which integrated development environment (IDE) you wish to use to develop your control - either Visual Studio 2017 (or later) or Visual Studio Code. Although the latter option does require some tinkering, I recommend it over traditional Visual Studio if at all possible, as it provides a far more streamlined development experience. Also, note that you will need to install the .NET Core 3.1 SDK if using Visual Studio Code.

Once you have installed all pre-requisite components, you can then initialise and create your first PCF component project. You can follow the steps outlined in this article to get started. Alternatively, check out the video below to see this, and all other steps mentioned so far in this section, in action:

Reviewing the PCF Component Manifest

Just as solutions have high-level properties/metadata that summarises your particular piece of functionality, a PCF component has a manifest which defines general properties relating to your component. Comprised of a single file, called ControlManifest.Input.xml, the manifest looks like this when creating a new component targeting a field:

<?xml version="1.0" encoding="utf-8" ?>
<manifest>
  <control namespace="jjg" constructor="MB400Sample" version="0.0.1" display-name-key="MB400Sample" description-key="MB400Sample description" control-type="standard">
    <!-- property node identifies a specific, configurable piece of data that the control expects from CDS -->
    <property name="sampleProperty" display-name-key="Property_Display_Key" description-key="Property_Desc_Key" of-type="SingleLine.Text" usage="bound" required="true" />
    <!-- 
      Property node's of-type attribute can be of-type-group attribute. 
      Example:
      <type-group name="numbers">
        <type>Whole.None</type>
        <type>Currency</type>
        <type>FP</type>
        <type>Decimal</type>
      </type-group>
      <property name="sampleProperty" display-name-key="Property_Display_Key" description-key="Property_Desc_Key" of-type-group="numbers" usage="bound" required="true" />
    -->
    <resources>
      <code path="index.ts" order="1"/>
      <!-- UNCOMMENT TO ADD MORE RESOURCES
      <css path="css/MB400Sample.css" order="1" />
      <resx path="strings/MB400Sample.1033.resx" version="1.0.0" />
      -->
    </resources>
    <!-- UNCOMMENT TO ENABLE THE SPECIFIED API
    <feature-usage>
      <uses-feature name="Device.captureAudio" required="true" />
      <uses-feature name="Device.captureImage" required="true" />
      <uses-feature name="Device.captureVideo" required="true" />
      <uses-feature name="Device.getBarcodeValue" required="true" />
      <uses-feature name="Device.getCurrentPosition" required="true" />
      <uses-feature name="Device.pickFile" required="true" />
      <uses-feature name="Utility" required="true" />
      <uses-feature name="WebAPI" required="true" />
    </feature-usage>
    -->
  </control>
</manifest>

The properties in control node are specified when creating your project for the first time using the pac pcf init command. Typically, the only values in this node you would change is the version, display-name-key and description-name key values. The version value should be updated each time you deploy an updated version of your component.

The manifest includes some additional nodes, which are worth reviewing in further detail:

property: Here, you define the various input properties that the component relies on and will be ultimately bound to when utilised. You can only tie PCF controls to a limited range of field types within the application, so it’s essential to know the limitations relating to this. For example, at the time of writing this post, it is not possible to bind a control to a lookup, Status or Status Reason field. You have additional options here to specify whether a property requires a value and whether the component should utilise a default value if none is specified. A PCF component can have multiple property nodes defined for it.
resources: Within this node, you must list all files that the component relies on to function correctly - whether this is additional HTML, CSS, or even other file types, such as images. Only one TypeScript file can be listed here, but you can have as many of all different file types as your component needs to function correctly.
feature-usage: Here, you can enable/disable additional features that your component can utilise within a model-driven app. By default, all of these are disabled, so you will need to uncomment the specific ones you need. Note, in particular, that you must explicitly enable the WebApi for use in your component before you can start calling its appropriate list of methods.

Just as you need to spend some time updating the properties of your solution each time your release, you should anticipate working in the manifest often. For the exam, having a good awareness of the manifest schema and how to enable/disable various properties within your code component should be sufficient.

End to End Development Cycle: Building, Debugging and Deploying a PCF Control

Microsoft provides a great online tutorial, that talks you through the steps involved to build your very first PCF Control, so there is no point me repeating this verbatim. However, I sometimes find the best way to understand a process is to see it in action. With this in mind, check out the video below, where I will guide you through all the steps involved to deploy out your very first PCF control into a model-driven app. The video will also show you how to debug your code component using the Power Apps Component Framework Test Environment:

Web API

As mentioned earlier, PCF controls can interact with the Dynamics 365 / Common Data Service Web API to perform platform-level operations. Similar to JavaScript, we do not need to worry about authentication when accessing the Web API in this way, but the list of available methods (at the time of writing this post) is significantly less. The current list of available operations is as follows and covers all basic CRUD operations targeting the application:

This state of affairs means that if, for example, you need to perform operations such as an Execute request, you would have to instead resort to a solution that uses client-side scripting instead.

Coming Soon: PCF Controls for Canvas Apps

A final note and, one which Microsoft will (I assume) eventually cover within the MB-400 exam itself, is that PCF controls are supported within canvas Power Apps as well. This capability is currently in public preview but, once released, will allow developers to straightforwardly utilise an existing PCF control within their canvas apps, without needing to rewrite their code. To find out more how to get started with this feature, check out the following Microsoft Docs article.

Further Tools / Resources

I’ve linked to numerous Microsoft Docs articles in this post surrounding PCF control development, and these should always be your first port of call when getting started on this subject. I would also recommend that you check out the following other resources too:

PCF Gallery: A free community website operated by Guido Preite, this site is an excellent resource for finding free PCF controls, that you can utilise or experiment further with.
Dynamics Ninja Blog: Ivan Ficko has blogged, delivered many sessions relating to PCF controls and also has numerous examples that he’s created as well. If you’re looking to go the next step with your PCF development, he is your man! 🙂
Todd Baginski’s YouTube Channel: Todd has also done videos on how to develop a PCF control and debug your components, which I would recommend watching.

PCF controls are an exciting new area within Dynamics 365 and the Power Platform. However, they are also a feature that is constantly changing. Be sure to refer to the latest documentation, as Microsoft releases new capabilities for PCF controls all the time. In next week’s post, we round off our discussion on how to extend user interfaces, by looking at how to set up a custom command button within a model-driven Power App.