1.4 Designing Reusable Power Apps Components and Custom Connectors

Reusability is a core architectural goal on PL-400: a well-designed component should be built once and consumed across many apps and forms, instead of being re-implemented every time a similar UI need appears. This section covers the three reuse mechanisms available for Power Apps UI, plus how to design a custom connector when no existing connector reaches a required external API.

Canvas Components and Component Libraries

A canvas component is a reusable grouping of controls — a custom card, a rating control, a navigation header — built once inside a canvas app and packaged with custom properties (input properties that configure it, output properties that expose its state back to the consuming screen). Publishing a component to a component library makes it available across multiple canvas apps in the same environment, so a design system (branded buttons, standard headers, validation banners) can be centrally maintained and versioned.

Key design considerations for canvas components:

• Components in a library are versioned; consuming apps must explicitly update to a new version, which protects existing apps from unexpected breaking changes.
• Components are limited to canvas app surfaces — they cannot be used inside a model-driven app form.
• Complex custom rendering (charts with unusual interactivity, camera/barcode integrations beyond built-in controls) still may exceed what a canvas component can express, pointing toward a PCF code component instead.

Code Components (PCF)

A Power Apps component framework (PCF) code component is a professionally coded (TypeScript/HTML/CSS) control that can be used as either a field component (renders a single column) or a dataset component (renders a grid/list of records), and — unlike a canvas component — works in both canvas apps and model-driven app forms and views. PCF is the right design choice when a requirement needs rich, highly interactive UI (a custom map, a Gantt chart, a signature pad) that exceeds what canvas controls or components can render, or when a control must be reused across both canvas and model-driven surfaces.

Reusable Client Scripting

JavaScript logic for model-driven forms should be organized into web resource libraries — shared .js files referencing named functions — rather than duplicated inline per form. A well-designed library exposes generic, parameterized functions (e.g., a single "required field" validator configured per form via event handler parameters) so the same script is registered across many forms and tables instead of being copy-pasted with small variations.

Designing Custom Connectors

When a requirement needs to call an external REST API that has no existing standard or premium connector, the solution is a custom connector. Designing one involves several decisions made up front:

1. Definition source — build the OpenAPI (Swagger) definition manually, import it from an existing OpenAPI file, or generate it from a sample Postman collection.
2. Authentication type — an API key, Basic authentication, or OAuth 2.0 (the connector stores the client ID/secret and token endpoint so users don't manage tokens themselves).
3. Host and base URL — the connector's root endpoint, with individual actions and triggers defined against it as HTTP operations (GET, POST, etc.).
4. Policy templates — reusable transformations applied to requests/responses at runtime without modifying the underlying API — for example, setting a fixed header, mapping a query parameter, or transforming a response's content type. Policy templates let a connector adapt to platform requirements without needing changes on the API side.
5. Sharing and lifecycle — a custom connector can stay personal to its creator or be shared/published through a solution so other makers in the environment (and, when the solution is deployed, other environments) can add it to their flows and apps.

Because a custom connector's data classification also participates in DLP policy grouping (covered in the previous section), its design should account for which DLP group it will fall into so it isn't blocked from combination with connectors it needs to work alongside in a flow.

Putting It Together

A typical PL-400 scenario asks you to choose between these options for the same UI problem. If the requirement is confined to canvas apps and is primarily visual composition, a canvas component is the lightest option. If it must also appear on a model-driven form, or needs behavior beyond what Power Fx can express, PCF is the correct answer. And whenever the requirement is "call this external API," the answer is a custom connector, not a plug-in or Azure Function — those are for logic that runs inside Dataverse's own pipeline, not for exposing an API to makers as a reusable action.