What it does

The decision about whether a specific piece of UI justifies a TypeScript control built with the Power Apps component framework, rather than an out-of-the-box control, a canvas component, a custom page, or a change to the requirement.

Key facts

• Code components are TypeScript, packaged into a Dataverse solution, and dropped onto a model-driven form, view or dashboard, or onto a canvas screen. They render in the same context and load with the rest of the page.
• The framework is on by default for model-driven apps. For canvas apps it's a per-environment feature a system administrator turns on under Settings > Product > Features.
• Canvas apps embed a copy of the component in the app definition; model-driven apps reference the environment's version. So two canvas apps in one environment can be running different versions of the same component, and updating a canvas app to a new version is a manual step in Studio.
• Increment at least the PATCH segment of the manifest version or the platform doesn't detect the change at all — no error, no update.
• Licensing follows the data. A component that reaches an external service directly from the browser rather than through a connector is premium, and it makes the whole app premium. Declare those domains in the manifest.
• Components have access to security tokens and data while rendering in Power Apps Studio. Microsoft's guidance is explicit: only import components from sources you trust.
• Code components aren't supported inside canvas component libraries, which rules out the most natural reuse pattern.
• Not supported for on-premises environments.

When to use / skip

A code component earns its keep on three conditions together: the platform genuinely can't render it, the need appears in more than one place, and someone will still be able to maintain it in three years. Miss any one of those and the answer is no. A calendar, a Gantt view, a signature capture, a specialised numeric input used across forty forms — those pass. A component built to save a maker four clicks on one screen does not, and it's the single most common thing you'll find in an inherited estate.

Check the ladder below it first, in order. Modern controls have absorbed a lot of what people used to write PCF for. A canvas component covers reuse within canvas. A custom page covers "we need a bespoke screen inside a model-driven app". Only when all three have been honestly tried does the framework become the answer rather than the habit.

The real cost isn't the build, which a competent developer does in days. It's the repository, the pipeline, the build agent, the version discipline, the security review for anything from GitHub, and a named person who reads TypeScript. Clients accept the first cost readily and the rest reluctantly, usually after you've left.

Configuration decisions

• Whether the component is genuinely reusable or a one-off, because that changes the solution strategy and the whole cost case.
• Segmented solution for components alone, or components sitting in the same solution as the apps and tables. Segmented if a separate team owns them or they're shared across environments.
• The publisher prefix and the versioning convention, both of which are effectively permanent once components are deployed downstream.
• Whether the component is classified premium through external service usage, and whether the client's licensing already covers that.
• Who reviews and approves third-party components before import, given the Studio security context.
• Whether you're prepared to accept the canvas embedding model, where each app carries its own copy and updates are manual.

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 the build mode to production in the project file.
• A canvas app can be imported into an environment without the matching component present. It works right up until it doesn't.
• Forgetting the manifest version increment produces the most confusing bug in the whole framework: everything deploys, nothing changes, nothing errors.
• Not every framework API is available in canvas apps. Check per API rather than assuming parity with model-driven.
• Community components are useful, widespread, and a supply-chain risk that survives your engagement. "We got it from GitHub" doesn't survive a security review.

Consultant notes

• Ask the question directly in the workshop: who maintains this after we leave? If the answer is a name, the component is viable. If it's "the platform team", find out whether that team writes TypeScript, because usually it doesn't.
• Price the lifecycle, not the build. Repo, pipeline, review gate, upgrade testing each wave, and a bus-factor plan.
• Set the publisher prefix and the solution strategy in week one. Changing either after downstream deployment is a rebuild, and clients never budget for it.
• Warn about the premium reclassification before the component is written. A component that makes the whole app premium is a licensing decision dressed as a technical one, and it should be taken by whoever owns the licence budget.
• When you inherit a bespoke component nobody can build any more, treat replacing it as its own piece of work with its own funding. Absorbing it into a change request is how these things become permanent.

---

Worth revisiting if code components ever become supported inside component libraries, or if the canvas versioning model changes