Pcf Development

PCF development

Build supportable Power Apps Component Framework (PCF) code components using current Microsoft platform contracts, explicit host constraints, secure data access, and solution-aware ALM.

When to invoke

• "Create a PCF field control for a model-driven app."
• "Review this ControlManifest.Input.xml."
• "Build a dataset component with React."
• "Why does this PCF control fail in a canvas app?"
• "Package and deploy this code component in a solution."

Platform decisions

Confirm these decisions before generating or changing code:

Do not assume that an API available in a model-driven app is available in a canvas app. Verify host-specific support in the current PCF API reference.

Component contract

Keep ControlManifest.Input.xml, TypeScript types, and runtime behavior aligned:

• Use a stable namespace, constructor, version, display keys, and description keys.
• Declare every input and output property with the correct usage, type, required state, and localization keys.
• Use a dataset only when the component truly consumes a collection; declare required columns and capabilities deliberately.
• Declare external domains under external-service-usage when the browser calls them directly.
• Request only the feature usage the component needs.
• Keep resource ordering deterministic and include generated type declarations.
• Validate the manifest with the installed PCF tooling instead of inventing schema elements.

Implement the lifecycle deliberately:

1. init stores framework callbacks and creates long-lived UI state.
2. updateView renders from the latest context and handles resize, visibility, dataset paging, and disabled state.
3. getOutputs returns only declared output properties.
4. destroy removes listeners, observers, timers, subscriptions, and framework resources.

Never trigger an unconditional render-update-output loop. Notify output changes only when component-owned output actually changes.

React and dependency strategy

• Prefer React controls and Power Platform platform libraries when the target host and tooling support them.
• Do not bundle React or Fluent dependencies that the selected platform-library mode owns.
• When platform libraries are not used, bundle external dependencies into the component bundle and review size, licenses, and browser compatibility.
• Keep host integration in a thin adapter and test domain behavior outside the framework lifecycle.
• Avoid direct global DOM mutation; render inside the provided container.

Security, privacy, and accessibility

• Do not store sensitive or durable data in localStorage or sessionStorage; Microsoft documents browser storage as insecure and unreliable for PCF state.
• Canvas PCF components must use connectors for authenticated data operations because custom authentication is not supported there.
• Treat manifest inputs, dataset values, URLs, and external responses as untrusted.
• Avoid innerHTML; when unavoidable, sanitize with a reviewed policy.
• Use least-privilege Dataverse access and never embed client secrets or tokens.
• Provide keyboard operation, visible focus, semantic roles, labels, sufficient contrast, zoom support, and screen-reader announcements.
• Respect high contrast, reduced motion, localization, and right-to-left layouts where applicable.

Tooling and ALM workflow

Use the repository's installed versions and inspect pac --version, Node.js, package manifests, and lockfiles before changing dependencies.

Typical component flow:

pac pcf init --namespace <namespace> --name <component> --template field
npm install
npm run build
npm test

Typical solution flow:

pac solution init --publisher-name <publisher> --publisher-prefix <prefix>
pac solution add-reference --path <component-project>
dotnet build

Prefer source-controlled solution projects and environment-specific configuration. Do not publish, import, or upgrade a production solution without the target environment, solution type, dependency analysis, approval, and rollback path.

Validation

Run the smallest existing checks that cover the component:

• TypeScript type-check and project build.
• Unit tests for state and rendering logic.
• Manifest and generated type validation through PCF tooling.
• Browser checks in every claimed host.
• Keyboard, screen reader, high contrast, responsive sizing, and localization checks.
• Solution build and import in a non-production environment.
• Performance checks for repeated updateView, large datasets, paging, and cleanup after navigation.

When validation cannot run, report the missing PAC CLI, environment, host, credentials, test project, or solution metadata explicitly.

Troubleshooting

Limits

• Use the power-platform-expert agent for broader Dataverse, Power Automate, governance, or architecture decisions.
• Verify licensing and tenant policies with the target administrator; do not infer them from source code.
• Do not claim an API, host, or preview feature is supported without current Microsoft documentation or target-environment evidence.

Output template

## PCF implementation result

**Host:** <model-driven|canvas|Power Pages>
**Binding:** <field|dataset|input>
**Status:** <implemented|reviewed|blocked>

### Contract
- Manifest changes: <summary>
- Lifecycle behavior: <summary>
- Data and licensing: <summary>

### Quality
- Security and privacy: <result>
- Accessibility: <result>
- Performance: <result>
- ALM and rollback: <result>

### Validation
- <command or host test>: <pass|fail|not run with reason>

Quality gate

• Host, binding, rendering strategy, data access, licensing, and delivery model are explicit.
• Manifest declarations match TypeScript inputs, outputs, resources, and capabilities.
• Lifecycle methods are idempotent and destroy releases resources.
• No unsupported canvas authentication or insecure browser storage is introduced.
• Accessibility and performance behavior are validated in every claimed host.
• Solution packaging and environment promotion preserve an approval and rollback path.
• Results distinguish executed validation from recommendations.

References

• https://learn.microsoft.com/en-us/power-apps/developer/component-framework/overview
• https://learn.microsoft.com/en-us/power-apps/developer/component-framework/limitations
• https://learn.microsoft.com/en-us/power-apps/developer/component-framework/manifest-schema-reference/