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.
PCF Controls Overview
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:
- 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.
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 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:
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.