Canvas apps on model-driven forms: the quick guide

One record. A better workspace. Two ways to bring them together.

A model-driven form keeps the record in view. A canvas app adds a guided experience around it: an intake flow, a call script or a focused task panel. The useful question is how tightly that experience should depend on its host form.

The built-in route, at a glance

Microsoft documents two designer paths for embedding a canvas app:

• Modern designer: open the solution’s table and main form, add the Canvas app component, and configure App name and App ID. Save, publish and share the app.
• Classic designer: add the canvas control to a required column that always has a value. Use Customize to create the embedded app and its ModelDrivenFormIntegration control.

Adding an existing app does not currently provide that integration control. For form data through ModelDrivenFormIntegration, Microsoft specifies creating the app through the classic designer. Its Item property exposes the host record.

Use the app’s unique name for reliable solution referencing across environments; the control checks it before falling back to App ID. Share the canvas app separately. Microsoft also points to custom pages as a newer integration option.

Read Microsoft’s full setup instructions →

One app, more places to work

My HTML-host approach starts with a standalone canvas app. A small web resource passes the saved record’s ID and table name into its launch URL. The app reads those parameters and retrieves the record through Dataverse.

Build the workspace once. Bring it to the record. This approach is a better fit when you want the same experience on several forms and through direct links, with a launch contract you can test independently. You control the wrapper, sizing, configuration and startup behavior instead of designing around a form-specific integration object.

• Reuse: keep one app usable both inside a form and as a standalone destination.
• Testing: launch it with an explicit record parameter to investigate the canvas experience separately.
• Control: define exactly which context the host sends and how the panel handles a missing record or environment configuration.

Choose by the integration you need

Choose the built-in control when its documented form integration meets the workflow. Choose the HTML host when standalone reuse and an explicit launch contract matter more than native form coupling. Consider a custom page when the experience belongs within the model-driven app’s navigation.

The HTML host is an alternative architecture, rather than a platform replacement. Start with one-way saved-record context, test sharing and permissions, and decide how saves and refreshes should behave before adding more integration.