D365Forge

Catalogue › Platform Engineering › pcf-controls

PCF controls

Department
Platform Engineering
Stages
Implement, Operate
Modules
All
Status
reviewed
Copilot Cowork
Platform Engineering plugin for Copilot Cowork, or this skill on its own: Download SKILL.md
Claude Code
/plugin install platform-engineering@d365forge
Licence
CC BY 4.0, by Simon Foote, Robert Peledie

Code components built with the Power Apps component framework let a model-driven app present data in ways standard controls cannot: a visual timeline, a signature pad on a technician's device, an inline map or a richer editable grid. They render inside the app's own lifecycle, so a well-built control feels native and a poorly built one slows every form it sits on.

Projects get into trouble when controls are built for cosmetic preference, when business validation lives in a control and nowhere else, or when community controls are imported without anyone reading the code. Another frequent problem is releasing a change without incrementing the control's version, so users keep running the old one.

When to use

Not this skill: solution-architecture:extend-or-configure to decide whether a control is justified, field-service:mobile-and-offline for the offline profile and mobile app set-up, and platform-engineering:plugin-design for server-side rules a control must never replace.

Questions to ask first

  1. What exactly can standard controls not do, and what does the user lose if one is used? This keeps controls to genuine needs.
  2. Where will the control run (main forms, views, custom pages, mobile, offline)? Each context changes which APIs and data are available.
  3. Is it bound to a column or a dataset, or does it fetch its own data? This decides the control type and its performance profile.
  4. Which accessibility standard must the organisation meet? It sets the testing bar before release.
  5. Who in the run team can maintain TypeScript and the build toolchain? Without that skill the control becomes an orphan.

Approach

Treat a code component as a small product with its own source, tests, version history and owner.

  1. Justify it and look for existing options. Check standard controls, Microsoft-provided components and reputable published controls first. If adopting a third-party control, review the source and maintenance history, be ready to own a fork, and refer its licence terms to the organisation's DPO or legal adviser where they are unclear.
  2. Choose the type. Field components bind to a column and suit input or display of a single value. Dataset components bind to a view or subgrid and suit alternative list or grid presentations. Keep components that fetch extra data through the Web API to a minimum, because each adds calls to every form load.
  3. Keep logic in the right place. The control presents and captures data. Rules that must always hold belong in Dataverse (business rules, plug-ins, column validation), because data also arrives through imports, flows and integrations that never render the control.
  4. Build for performance. Keep bundles small, use the platform-provided React and Fluent UI libraries where supported (check current Microsoft Learn documentation), avoid heavy work on every update cycle and debounce user input before writing values back.
  5. Build for everyone. Support keyboard navigation, screen readers, high contrast and the app theme. Test on the devices and form factors users actually have, including Field Service Mobile and offline mode where relevant.
  6. Package properly. Initialise the project with the Power Platform CLI, keep source in the repository, build in the pipeline and ship controls in a component solution under the organisation's publisher. Increment the manifest version on every release so clients pick up the change.
  7. Test. Unit test the logic, use the test harness during development and check the control in a real app, on real devices, before release.

Outputs

Scale notes

SMB

Prefer existing controls or configuration, because a bespoke control is a significant support commitment for a small team. If one is essential, make sure the customer owns the source and a partner support arrangement covers it. Accessibility testing must not be dropped to save time.

Enterprise

Maintain a catalogue of approved controls with named owners, a shared component library aligned to the organisation's design system, automated accessibility checks in the build and design authority approval for each new control.

Hand-offs

platform-engineering:solution-layering places the control in a solution, platform-engineering:deployment-pipelines builds and releases it, and testing-quality:regression-automation keeps it covered. Reviewer sign-off: design-authority:customisation-challenge before build and design-authority:standards-conformance before release.

Sources

references/sources.md in this skill lists the outside authorities for the questions here, what each is authoritative for, and what you may do with it. Check the current Microsoft Learn documentation before stating how a feature behaves, because Dynamics 365 changes monthly, and cite what you used.

Never

Sources for this skill

Application lifecycle management with Microsoft Power Platform

Dataverse developer documentation

Microsoft Copilot Studio documentation

Overview of pipelines in Power Platform

Power Platform Well-Architected

Web Content Accessibility Guidelines (WCAG) 2.2

Credit

This skill was created by Simon Foote and Robert Peledie as part of D365Forge, licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Credit them when you share or adapt it; see https://github.com/SimonFoote-greensparx/D365Forge/blob/main/NOTICE.md.