Power Apps Component Framework (PCF)

What is Power Apps Component Framework?

Power Apps Component Framework, almost always shortened to PCF, is the way developers build reusable code components for Power Apps. A code component can replace or extend a standard field, a dataset grid, or another piece of the interface, using web technology instead of the built-in controls.

It exists for the moments where the standard controls and low-code building blocks run out. A scheduling board, a map view, a colour picker, a rich text editor, or an input control with domain-specific validation: these are the kinds of things makers cannot assemble from the default toolbox, so a developer writes the rendering and interaction logic instead.

The same technical foundation works in both model-driven apps and canvas apps. The available APIs differ per host, so a component that calls the Dataverse Web API will run in a model-driven app but not on a canvas screen, where that API is not available.

The parts of a code component

A code component is two things bundled together: a manifest and the code it describes.

The manifest is an XML file that declares the component name, version, the properties it binds to, any datasets it consumes, and the resource files it needs. It also declares whether the component talks to an external service, which matters for both behaviour and licensing.

The implementation is written in TypeScript and built together with CSS and any other local resources into a single bundle. A field component receives one or more bound property values. A dataset component works with a whole collection of records, along with the columns, sorting, filtering, and paging around them.

The finished component is packaged as part of a Dataverse solution. That is how it travels between Power Platform environments alongside the apps, tables, and other objects it depends on.

The component lifecycle

The framework drives the component through a small set of methods, and your code fills them in. init prepares the component and builds the initial interface. updateView runs whenever the bound data, container size, or other context changes. getOutputs hands changed values back to the host, and destroy tears down event listeners and timers when the component is removed from the page.

The fragment below shows only the shape of updateView, formatting a bound number for a Belgian locale:

public updateView(context: ComponentFramework.Context<IInputs>): void {
  const value = context.parameters.amount.raw ?? 0;
  this.label.textContent = new Intl.NumberFormat("nl-BE").format(value);
}

A real component does far more than this. It handles keyboard access, error states, resizing, and null values that the host passes in before the data is ready. Treat the lifecycle methods as the skeleton, not the finished control.

PCF versus the component library

A Power Apps component library holds low-code components built with Power Fx and the existing canvas controls. Makers create and publish those without any build tooling, and other apps pick them up through the normal update flow.

PCF is a different tool for a different job. It uses web code and the framework APIs, so it fits new rendering, complex interaction, dataset grids, and access to supported client capabilities that Power Fx cannot reach. The two are not rivals: a canvas component can even host a PCF control, but then it inherits that control's build process and licensing terms.

Reach for PCF because you genuinely need custom code, not just to recolour a standard control. Extra code brings version management, security review, testing, and long-term maintenance with it.

PCF versus a web resource

An HTML web resource runs as a separate piece of web content and sits loosely alongside Power Apps. A PCF component is loaded by the host itself and gets typed access to context, metadata, and the bound data. That tighter integration is why PCF fits controls on forms, views, and canvas screens where a web resource feels bolted on.

It does not mean any browser code is fair game. Only documented APIs are supported, and reaching into the host application's page structure or injecting scripts through global variables is not. Components that do this can break without warning when Microsoft changes the host.

Security and external services

Client code is visible to anyone who wants to read it, and it runs with the permissions of the signed-in user. Secrets do not belong in JavaScript, in the manifest, or in configuration properties, because none of those are private.

A component that calls an external service straight from the browser has to declare that in the manifest. That declaration can carry licensing consequences and it puts CORS, authentication, and privacy squarely on your plate. Dataverse and connector permissions still apply underneath. A polished interface is not a substitute for server-side security, and it should never try to be one.

What to watch out for with PCF

Version bumps are mandatory. Dataverse only picks up your changes if you raise the component version in the manifest. Import a new build with the same version number and the old code keeps running.

Development builds do not belong in production. They are larger and slower, and can be blocked from deployment for their size. Ship release builds, ideally through an automated pipeline so nobody forgets to swap them.

Test across hosts and conditions. Check different clients, themes, screen sizes, and data volumes, and confirm keyboard access, labels, focus handling, and contrast. A control that only ever saw a handful of development records will surprise you in production.

Mind the API differences. Not every framework API exists in every host. Confirm each API you rely on is supported in model-driven apps, canvas apps, or Power Pages before you build around it.