Custom PCF controls vs embedded canvas apps in model-driven forms

A model-driven form is a fine thing until someone wants a map, a drag-and-drop scheduler, a visual configurator, a signature pad, or a pane that pulls live data from a system outside Dataverse. Then you need custom UI inside the form, and Power Platform gives you two very different tools for it: a Power Apps component framework (PCF) control, which is code that replaces or extends a field or a grid, or an embedded canvas app, which is a whole low-code app rendered inside a form section. They overlap enough that projects pick the wrong one regularly.

What each actually is

A PCF control is a TypeScript component built with the PCF tooling, packaged in a solution, and bound to a field, a dataset, or a subgrid on the form. It receives its data through a context object the platform provides, renders with whatever framework you choose (React is the common one), and writes values back through the same context. It is a first-class part of the form: it resizes with it, respects the form's read-only state, and behaves the same on web and mobile. See PCF controls in Power Apps.

An embedded canvas app is an ordinary canvas app that is placed on a model-driven form and receives the current record as context through the ModelDrivenFormIntegration control. It is built in the canvas designer with Power Fx, uses connectors for data, and lives in the same solution as the form. It runs in an iframe within the form section.

Data access is the first fork

A PCF control bound to a field sees that field. A dataset PCF control sees the rows of a view or subgrid. Beyond that, it can call the Dataverse Web API through the context, and it can call external endpoints, but every external call is code you write and authenticate yourself.

An embedded canvas app has the full connector library: Dataverse, SharePoint, SQL, Office 365, and hundreds of others, with authentication handled by the platform. If the custom UI needs to pull from three external systems, the canvas app has them wired in an afternoon.

So: data that is on the form or in Dataverse points to PCF; data scattered across connectors points to canvas.

Performance and fidelity

PCF controls load as part of the form and feel native. A well-built one is indistinguishable from a platform control. They work in offline mode on the mobile app when built for it, and they respect the form's theming and accessibility conventions if the developer does.

Embedded canvas apps add an iframe, a separate app load, and a visibly different rendering surface. On a fast connection with a small app the delay is a second or two; on a slow one, or with an app that has grown, users notice. They do not work offline in the model-driven mobile app. Layout is fixed-size within the form section, and making a canvas app look like it belongs on the form takes deliberate effort.

For anything the user sees on every record load, PCF. For something opened deliberately, such as a side panel or a tool the user reaches for occasionally, canvas is acceptable.

Who builds and maintains it

PCF is a developer artefact: Node tooling, TypeScript, a build pipeline, unit tests if the team is disciplined. When the developer leaves, the next one needs the same skills. Updating the control means rebuilding and reimporting the solution.

An embedded canvas app is a maker artefact. A functional consultant or a capable business user can adjust the layout, add a connector, or change a formula without a build. That is a real advantage in organisations without a permanent development team, and a real risk in organisations without governance, because the app can drift far from what was tested.

Licensing

A PCF control that only uses Dataverse and the form's context is covered by the user's Dynamics 365 or Power Apps licence. A PCF control that calls premium external services does not change the licence position by itself. An embedded canvas app that uses premium connectors requires the user to hold a licence that covers them, which Dynamics 365 enterprise licences generally do, but check; a canvas app using a premium connector for users on a Team Member licence is a common surprise.

Where each is clearly right

PCF: replacing a field's editor (a rich text control, a colour picker, a rating), rendering a subgrid differently (a Kanban, a timeline, a map of records), anything on the main form that must be fast and must work offline, and controls you intend to reuse across many forms and tables.

Embedded canvas app: a self-contained tool that pulls from external connectors (a document checklist from SharePoint, a pricing lookup from an external SQL database), a guided data-entry wizard that would be awkward as form logic, and prototypes that need to exist by Friday.

Where each is clearly wrong

A PCF control that reimplements a whole application in one field. Nobody wants to maintain that. An embedded canvas app on the main tab of the most-used form, loading on every record open, with a dozen connectors. Users will complain within the week.

What breaks in practice

PCF controls built against an old version of the framework that stop working after a platform update; keep the tooling current. Canvas apps embedded on forms that were shared with the wrong audience so half the users see an error. Either type that hard-codes environment-specific URLs; use environment variables.

Stability verdict

Both are mature and both are supported. PCF is the more durable investment for anything central to the user experience. Embedded canvas apps are the faster path and a reasonable permanent answer for peripheral tools. Read canvas apps vs model-driven apps if the real question is whether the whole app should have been canvas to begin with.