4.6 Packaging, Deploying & Consuming a PCF Component

Writing a working index.ts is only part of shipping a PCF component. Before an organization's makers can drop it onto a form or a view, the component has to move through a local test loop, get packaged into a proper Dataverse solution, and be applied to a specific field, view, or subgrid.

Fast Local Iteration

The quickest feedback loop, before touching any live environment, is the built-in test harness:

npm start

This launches pcf-scripts start, which opens a browser-based harness that simulates a bound field or dataset without requiring a connected Dataverse environment. It's the right tool for iterating on rendering logic, styling, and basic interaction, but it cannot exercise environment-dependent behavior such as real context.webAPI calls against live data or security-role-based field behavior.

Quick Deploy to a Real Dev Environment

Once the component needs to be tested against real data or inside an actual form, pac pcf push deploys it directly into a connected development environment:

pac pcf push --publisher-prefix contoso

This command builds an unmanaged solution containing the component behind the scenes and imports it automatically, which makes it ideal for a solo developer's fast iterate-and-test cycle. It is not, however, an ALM promotion mechanism — it's a shortcut for one developer's own dev environment, not a way to move a component through test, UAT, and production.

Packaging for Real ALM

Promoting a component through environments the way other solution components (tables, plug-ins, flows) are promoted requires packaging it into a proper Dataverse solution project:

1. pac solution init --publisher-name Contoso --publisher-prefix contoso — scaffolds a solution project.
2. pac solution add-reference --path <path-to-pcf-project> — links the component's project into the solution project so its build output becomes part of the solution package.
3. Build with MSBuild (msbuild /t:build /restore, or the equivalent dotnet build for SDK-style projects) — restores NuGet dependencies and produces a solution .zip containing the compiled bundle, the manifest, and any resources. A Debug configuration build typically produces an unmanaged package for dev iteration; a Release configuration, when set up for it, produces a managed package suitable for downstream environments.
4. Import the resulting .zip through Solution Explorer in the maker portal, pac solution import, or a Power Platform Build Tools pipeline task — unmanaged into dev, managed into test, UAT, and production, following the same solution-layering discipline that governs every other component type.

Consuming the Component

Once imported, a component still has to be applied somewhere — importing the solution alone doesn't change any form's appearance:

• Field components are added from the field's properties panel in the form or app designer, under its "Components" section; the developer configures which input/output properties map to which values and which form factors (web, phone, tablet) use the custom rendering versus the platform default.
• Dataset components are applied the same way to a view or a subgrid, replacing the default grid renderer and binding to that view's or subgrid's columns.
• Canvas apps can use the same component if code components are enabled for canvas apps at the environment level (an environment setting that must be turned on) and the component doesn't depend on model-driven-only behavior.

Each of these — a specific field, a specific view, a specific subgrid — is a separate configuration choice; applying a component to one field does not make it available anywhere else the same table appears without configuring it there too.

Versioning Matters

Dataverse identifies whether a rebuilt component is actually new by the <control version="..."> attribute in the manifest. If that version isn't incremented (or auto-incremented by tooling) before rebuilding and re-importing, the platform can fail to recognize the updated bundle as a change, leaving users looking at a cached, stale rendering even though the solution import reported success. Because PCF components are ordinary Dataverse solution components, they follow the same dependency-tracking, layering, and pipeline-based promotion practices covered in the Build Power Platform Solutions domain — there is no separate ALM story just for code components.

One Component, Multiple Placements

A single component definition can be applied to several places at once — the same rating control might be added to a field on the account form, a different field on the opportunity form, and a column inside a subgrid — and updating the underlying component in one place, through a new solution import, updates every placement that references it, without needing to reconfigure each usage individually. This many-to-one relationship (one component, many bindings) is why versioning discipline matters so much: a botched update to a widely reused component propagates its problem everywhere the component is applied the next time the solution is imported, rather than staying isolated to a single form.

Solution Checker

Before a component reaches a shared environment, running the Solution Checker against the packaged solution catches common code-quality and reliability issues — unhandled promise rejections, use of deprecated APIs, or accessibility problems in generated markup — the same automated review applied to plug-ins and other solution components. Treating Solution Checker as a required gate before promoting a component out of a development environment, rather than an optional linting pass, keeps issues from surfacing for the first time in test or production, where they are far more disruptive to diagnose and fix.