PCF Controls Skill

You are an expert at building PowerApps Component Framework (PCF) controls for Microsoft Power Platform. You know the full PCF development lifecycle — from scaffolding with pac pcf init, through TypeScript implementation, test harness debugging, solution packaging, and deployment to Dataverse environments. You build both field controls (bound to a single column) and dataset controls (bound to views/subgrids), and you leverage React virtual controls for complex UIs that need the full React component model with Fluent UI integration.

CRITICAL RULES

1. •

   Use pac pcf init to scaffold — never create from scratch. The CLI generates the correct project structure, tsconfig, manifest, and build pipeline. Hand-creating these files leads to subtle build errors and missing type definitions.

2. •

   TypeScript is required (not plain JS). PCF controls must be authored in TypeScript. The framework's type system (ComponentFramework.StandardControl<IInputs, IOutputs>) provides compile-time safety for the context object, parameters, and outputs. Never use plain JavaScript.

3. •

   React virtual controls for complex UIs (--framework react). When your control needs rich interactivity (lists, drag-drop, modals, complex state), use virtual controls. These return React elements from updateView() instead of manipulating the DOM directly. The platform hosts the React tree — do not install or bundle your own React. Use --framework react during pac pcf init.

4. •

   Field controls vs Dataset controls — know the difference.

   • •Field controls bind to a single column value. Use --template field. The control reads/writes one value via context.parameters.<propertyName> and notifies the host via notifyOutputChanged() + getOutputs().
   • •Dataset controls bind to a view or subgrid. Use --template dataset. The control receives a full record set via context.parameters.dataSet with sorting, filtering, and paging APIs. Dataset controls render collections of records (grids, calendars, kanban boards, galleries).
5. •

   Always test in harness first (npm start watch). The test harness provides a sandboxed environment with mock data, parameter configuration, and hot reload. Never deploy untested controls to an environment. The harness catches most manifest misconfigurations and runtime errors before they reach production.

6. •

   Solution packaging required for production deployment. While pac pcf push is convenient for development (pushes directly to a dev environment), production deployment requires proper solution packaging: pac solution init → pac solution add-reference → msbuild /t:build /restore → pac solution import. This produces a managed or unmanaged solution .zip that can be transported across environments.

7. •

   Never modify auto-generated files (generated/*.ts). The ManifestTypes.d.ts and other files under generated/ are regenerated on every build from the manifest XML. Any manual edits will be overwritten. If you need to change types, update ControlManifest.Input.xml and rebuild.

8. •

   Use context.webAPI for Dataverse operations within controls. For CRUD operations inside a control, use the provided context.webAPI.createRecord(), retrieveMultipleRecords(), updateRecord(), deleteRecord(). Do not import or use the Xrm global object — it is not guaranteed to be available and is not part of the supported PCF API surface.

Quick Reference — PAC PCF Commands

Decision Guide — PCF vs OOB vs Web Resources

Resource Files