What it does

The Power Apps component framework lets a developer build a control in TypeScript, package it into a Dataverse solution, and drop it onto a model-driven form, view or dashboard, or onto a canvas app screen. Unlike an HTML web resource, a code component renders in the same context and loads at the same time as everything else on the page.

Key facts

• The framework is enabled for model-driven apps by default. Canvas apps need Power Apps component framework for canvas apps turned on per environment under Settings > Product > Features, and that takes a system administrator.
• It isn't supported for on-premises environments.
• Licensing follows the data, not the code. A component that reaches external services or data directly through the browser rather than through a connector is premium and makes the app premium. Declare those domains in the manifest with an <external-service-usage> node.
• Components have access to security tokens and data while rendering in Power Apps Studio. Microsoft's warning is explicit: only import components from sources you trust. That exposure doesn't exist when the app is played.
• Canvas apps embed a copy of the component inside the app definition. Model-driven apps reference the version in the environment.
• Because of that, two canvas apps in the same environment can run different versions of the same component. One app can't run two versions.
• Updating a canvas app to a new component version is manual: bump the version in ControlManifest.Input.xml, reopen the app in Studio, accept the Update prompt, save and publish. Skip it and the app keeps running the old version even though it no longer exists in the environment.
• Increment at least the PATCH segment of the manifest version or the change isn't detected at all. pac pcf version --strategy manifest does it for you.
• pac pcf push deploys into a solution you name, or into a temporary unmanaged PowerAppsTools_<namespace> solution if you don't.
• Code components aren't supported inside canvas component libraries.

When to use / skip

Reach for PCF when the platform genuinely can't render what the business needs — a calendar, a Gantt view, a specialised input, a third-party visualisation — and when that need shows up in more than one place. Skip it when a canvas component, a custom page or a well-configured out-of-the-box control gets you 80% there, because a code component brings a build pipeline, a versioning story and a developer dependency that the client has to keep funded. The most common mistake is a bespoke component built to save a maker four clicks, which then blocks an upgrade three years later.

Configuration decisions

• Segmented solution for components alone, or a single mixed solution with the apps and tables — segmented if a fusion team owns them or they're shared across environments.
• Whether the component is classified premium via <external-service-usage>, and whether the client's licensing already covers that.
• Which publisher prefix the components use, since it has to match across environments and can't be casually changed later.
• The versioning convention, and whether MAJOR and MINOR track the enclosing solution version.
• Who reviews and approves third-party components before import, given the Studio token exposure.

Gotchas

• Build in development mode and push it and you get a bundle that's slow at runtime and sometimes too large to import. Set PcfBuildMode to production in the pcfproj.
• Forget to increment the manifest version and nothing changes anywhere, with no error to tell you why.
• A canvas app can be imported without the matching component being present in the environment. It works right up until it doesn't.
• Third-party components from the community are common, useful, and a real supply-chain risk, because of the Studio security context. Someone has to own that decision.
• Not every framework API is available in canvas apps. Check per API rather than assuming parity with model-driven.

Consultant notes

• Price the whole lifecycle, not the build. A code component needs a repo, a pipeline, someone who can read TypeScript, and a plan for what happens when they leave.
• Set the publisher prefix and solution strategy in week one. Changing either after components are deployed downstream is a rebuild.
• Warn the client that a premium-classified component pushes the whole app premium. That's a licensing conversation, and it should happen before the component is built.
• Establish a review gate for community components. "We downloaded it from GitHub" is not an answer that survives a security review.

---

Worth revisiting if code components ever become supported inside component libraries, or if canvas version handling changes.