Designing UX Components: Canvas, PCF & Client Scripts

Three paths to custom UX

Decision matrix: Which component type?

Choose based on where the component runs and what skills you have

Factor	Canvas Component	PCF Code Component	Client Script
Language	Power Fx (no-code)	TypeScript + React	JavaScript
Runs in	Canvas apps only	Canvas + model-driven apps	Model-driven apps only
Skill level	Maker (citizen developer)	Pro developer	Pro developer
Reusability	Component library (canvas)	Solution package (any app)	Web resource (model-driven)
External APIs	Via connectors in the host app	Via Web API feature in PCF	Via Xrm.WebApi or fetch
Access to device	Limited (camera via control)	Device API (camera, location, barcode)	No
Custom rendering	Power Fx layout only	Full HTML/CSS/React rendering	DOM manipulation (fragile)
Best for	Reusable form sections, branded inputs	Rich visualisations, custom grids, maps	Form logic, field visibility, validation

Quick decision flow

Ask these questions in order:

1. Does it need to work in a model-driven app? → If yes, use PCF or client script (not canvas component)
2. Is it purely form logic (show/hide, validate, set values)? → Client script
3. Does it need custom visual rendering? → PCF code component
4. Is it a reusable form section for canvas apps only? → Canvas component
5. Does it need device access (camera, GPS)? → PCF code component (Device API)

💡 Scenario: Marcus chooses the right component

Marcus Chen is an ISV developer at NovaSoft Solutions. He is building a product catalogue app that will be sold on AppSource. The catalogue needs:

1. A custom star-rating control that works in both canvas and model-driven apps → PCF component — needs to work cross-app and needs custom rendering
2. A branded header section reused across 5 canvas apps → Canvas component library — canvas-only, reusable across apps, no code needed
3. Auto-populate a “Region” field when the user selects a country on a model-driven form → Client script — form-level logic in model-driven app, no custom rendering needed

Each requirement maps to a different component type based on where it runs and what it does.

Designing for reuse

The best components are built once and used many times. Here are design principles for each type:

Canvas components

• Use custom properties — input properties for configuration, output properties for data, function properties for callbacks
• Keep components stateless where possible — pass data in, emit events out
• Component libraries let you share components across multiple canvas apps in the same environment
• Version carefully — updating a library component updates all apps that use it

PCF code components

• Design the manifest first — the ControlManifest.Input.xml defines what data the component accepts and returns
• Field vs dataset binding — field components bind to a single column; dataset components bind to a view or collection
• Package as a solution — PCF components travel in Dataverse solutions for ALM
• Avoid tight coupling — don’t hardcode table names or column names; use the manifest to accept them as parameters

Client scripts

• One web resource per feature area — don’t put all scripts in one massive file
• Use the formContext pattern — never use the deprecated Xrm.Page; always receive executionContext and call getFormContext()
• Register event handlers through the form designer — not in code (makes them visible to other makers)
• Namespace your functions — NovaSoft.Claims.onLoad() not onLoad() to avoid conflicts

Question

When should you use a PCF component instead of a canvas component?

Click or press Enter to reveal answer

Answer

Use PCF when: (1) the component must work in model-driven apps, (2) you need custom HTML/CSS rendering, (3) you need device access (camera, GPS, barcode), or (4) you need to call the Dataverse Web API directly from the component. Canvas components are limited to Power Fx and canvas apps only.

Click to flip back

Question

What is the difference between field-level and dataset-level PCF components?

Click or press Enter to reveal answer

Answer

A field-level PCF component binds to a single column value (e.g., a star-rating control bound to a number field). A dataset-level component binds to a collection of records (e.g., a custom grid or chart showing multiple rows). The binding type is defined in the component manifest.

Click to flip back

Question

Why should you use formContext instead of Xrm.Page in client scripts?

Click or press Enter to reveal answer

Answer

Xrm.Page is deprecated. formContext is the modern pattern — you receive the execution context in your event handler, call getFormContext(), and use that to interact with form controls. It also supports multi-session apps where multiple forms may be open simultaneously.

Click to flip back

Knowledge Check

Marcus needs to build a barcode scanner control that works in both canvas apps and model-driven apps. The control should open the device camera, scan a barcode, and return the scanned value to the form field. Which approach should he use?

AA canvas component using the Barcode scanner controlBA PCF code component using the Device APICA client script using the navigator.mediaDevices APIDA Power Automate flow with the AI Builder barcode reader

Check Answer

Knowledge Check

A consulting team needs to add form validation to a model-driven app: when the Priority field changes to 'Critical', the Description field must become required and a notification banner must appear. Which approach is most appropriate?

AA business rule that sets Description as required when Priority = CriticalBA PCF code component that monitors the Priority field and shows a bannerCA client script that handles the OnChange event for Priority, sets Description as required, and displays a form notificationDA canvas component embedded in the model-driven form

Check Answer

🎬 Video coming soon

Next up: Designing Platform Extensions — custom connectors, plug-ins, custom APIs, and Power Fx functions.