Exam PL-400 Revision Notes: Creating a Power Apps Component Framework (PCF) Control

Welcome to the thirteenth post in my series focused on providing a set of revision notes for the PL-400: Microsoft Power Platform Developer exam. Previously, we dived into our first code related topic in the series by evaluating the capabilities within the client scripting model, accessed primarily via JavaScript. 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’s easy to get a PCF control deployed out into any Power App. 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 Power Apps Component Framework (PCF) component

describe the PCF component lifecycle<

initialize a new PCF component

configure a PCF component manifest

implement the component interfaces

package, deploy, and consume the component

configure and use PCF Device, Utility, and WebAPI features

test and debug PCF components by using the local test harness

The development technologies involved as part of PCF components differ significantly from the areas those with previous experience of Dynamics CRM / 365 will likely know. Therefore, let’s jump in to review this in further detail and 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. 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. 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 within 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 embed 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 PL-400 exam specification. I believe this should tell you all you need to know and 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 a Power App, Power Apps Component Framework (PCF) controls are now here and entirely at our disposal. 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 alter the behaviour of the elements described earlier (fields & views) and support additional capabilities, such as accessing 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 simultaneously as the form itself, users get a completely seamless experience using a model-driven app with PCF controls attached.
They are developed using modern web technologies, such as NPM, Node.js and TypeScript.

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.
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 that 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 Power Platform developer can build out a PCF control without issue; the sign of an excellent developer is one who can identify the appropriate usage cases for themand not necessarily resort to using them as a first-preference solution if others can fit the gap.

Technology Areas Involved

To a degree, PCF controls are an anomaly 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 frameworks targeted towards rapid web development. This circumstance can be a potential blocker when traditional .NET developers start 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 use 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. Alternatively, you could look to leverage established frameworks such as Fluent UI, which has the advantage of removing a lot of headaches when styling and building out your interfaces.
CSS: Whereas HTML can be best thought of 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’s 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. Our TypeScript files will contain all of the logic and core functionality of a PCF control.
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 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, we must install a specific CLI for developing PCF controls. The CLI will provide a range of commands to build, test and deploy your components as you build them out.

You can find further details on all these setup steps 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 requires some tinkering, I recommend it over traditional Visual Studio if 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.

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 that 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="PL400Sample" version="0.0.1" display-name-key="PL400Sample" description-key="PL400Sample 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 the 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. You should update the version value 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 impossible to bind a control to a lookup, Status or Status Reason field. You have additional options 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 your solution’s properties each time you release it, 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 an excellent online tutorial that talks you through the steps involved to build your very first PCF Control, so there is no point in 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 Microsoft Dataverse Web API to perform platform-level operations. Like 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.

Using PCF Controls within Canvas Apps and Portals

As noted earlier, PCF controls are supported within canvas Power Apps as well. This capability allows developers to utilise an existing PCF control within their canvas apps straightforwardly without rewriting their code. To find out more about how to get started with this feature, check out the following Microsoft Docs article. It’s also worth noting that PCF controls will be coming to Power Apps portals in the future, given this functionality is currently in preview. This topic may (eventually) be assessed as part of the PL-400 exam.

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 the 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 has numerous examples that he’s created. 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 developing a PCF control and debug your components, which I would recommend watching.
Dianamics PCF Lady: Diana Birklebach’s blog is an excellent resource for when you need to dive deep into the technical inner workings of PCF controls. Diana’s knowledge of PCF controls is staggering! 🤯
Professional PCF for Model-Driven Apps: You should already be aware of the fantastic work that Scott Durow has done for the Business Applications community. This (paid) course provides a unique opportunity to learn how to build an effective and professional PCF control for your apps and is well worth the investment.

PCF controls are an exciting new area within 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. Next time, we round off our discussion on extending user interfaces by looking at how to set up a custom command button within a model-driven Power App.