PCF controls in Power Apps

The Power Apps Component Framework (PCF) lets developers build custom UI controls in TypeScript and ship them as reusable components inside model-driven apps and canvas apps. They're how you cross the boundary between Power Apps's built-in controls and pixel-perfect custom UI, without leaving the platform.

What PCF is. A PCF control is a self-contained TypeScript bundle (HTML + CSS + TS, optionally with React inside) that the Power Apps runtime hosts inside a form, view, or canvas screen. The control exposes input parameters (bound to Dataverse columns or canvas variables), receives a context object with data and APIs, renders UI, and writes back via the platform's APIs. To the user, the control feels native; to the platform, the control is a packaged solution component.

When to use a PCF control.

• Model-driven app forms where the default field controls don't fit: a slider, a colour picker, a custom rating widget, a map embedding, a barcode scanner, a Gantt chart, a kanban board.
• Model-driven views where the standard grid isn't enough: a custom card view, a calendar view, an editable spreadsheet view.
• Canvas apps where the built-in controls don't deliver a needed UX pattern.
• Reusable across many apps and customers — author once, package once, install many times.

When not to use PCF. Simple display tweaks belong in form configuration. Complex business logic belongs in JavaScript event handlers, Power Automate, or Dataverse plug-ins. PCF is specifically for UI components that present and capture data in non-standard ways.

The toolchain.

• Power Platform CLI (pac) — the command-line tool for scaffolding, building, packaging, and pushing PCF projects.
• Visual Studio Code — the editor of choice, with TypeScript and React extensions.
• Node.js — required for the build.
• TypeScript — the language. Microsoft provides type definitions for the PCF API.

Project structure. A PCF project contains:

• ControlManifest.Input.xml — the manifest declaring the control's name, input parameters, output events, and metadata.
• index.ts — the entry point implementing IInputs/IOutputs interfaces with init, updateView, getOutputs, destroy methods.
• React or vanilla DOM code rendering the actual UI.
• CSS for styling.

Packaging and deployment. pac pcf init scaffolds a project; pac pcf push builds and pushes to a Dataverse environment for testing; pac solution add-reference adds the PCF project to a solution; the solution exports as managed and installs into target environments. Source control lives in Git.

Performance. PCF controls run client-side in the user's browser. Heavy rendering or large data fetches degrade the form load time. Use virtualisation for long lists, lazy-load images, batch Dataverse Web API calls. Profile in Chrome DevTools.

Distribution. PCF controls can be shipped as part of an ISV's AppSource solution, made internal to one customer through a custom solution, or open-sourced (the PCF Gallery at pcf.gallery is a community-maintained catalogue of free PCF controls).

Limits.

• PCF controls don't have access to all Dataverse SDK methods; the context.webAPI is the standard data path.
• Some browser APIs (clipboard, geolocation) need permissions.
• Authoring PCF requires developer skill — this is genuine code, not low-code.

Operational reality. A small PCF library — 5 to 15 controls — covers most customers' bespoke UI needs without ever requiring more.