What it does

Canvas apps can be surfaced outside the Power Apps player: in an iframe on a website or Power BI dashboard, on a SharePoint page through the Power Apps web part, inside Teams, and on a model-driven form as an embedded canvas app. Each route has its own auth path, sizing behaviour and set of restrictions.

Key facts

• The iframe URL is https://apps.powerapps.com/play/[AppID]?source=iframe, or https://apps.gov.powerapps.us/play/[AppID] for GCC. The older web.powerapps.com/webplayer form redirects but shouldn't be used in new work.
• Supported URI parameters are tenantid for guest access, screenColor to control the colour shown while the app loads, source as a descriptive label, and any custom parameters read with Param(). Custom parameters are read at launch only — changing one means relaunching the app.
• Add allow="geolocation; microphone; camera" to the iframe for those capabilities to work in Chrome.
• Only Power Apps users in the same tenant can access an embedded app. If the host site uses Entra authentication there's no second sign-in; anything else prompts inside the iframe.
• Embedding in a native desktop or mobile application isn't supported. First-party integrations such as Power Apps in Teams are the exception.
• SharePoint Online doesn't need an iframe — use the Power Apps web part.
• On a model-driven form, three embedded canvas apps can be enabled per form for the Web client type and one for Tablet and Phone. Exceed three on Web and you get an explicit error. The canvas app control itself is only supported for the Web client type.
• Embedded canvas apps must be published separately from the host form. Publishing the form doesn't publish the app.
• ModelDrivenFormIntegration.Item is read-only. Writing back means the Dataverse connector, and if you write back data the form is displaying, the form shows stale values until refreshed — RefreshForm handles that.
• Offline and device capabilities — barcode scanning, camera capture, file attachment — aren't supported in embedded canvas apps on forms.

When to use / skip

Embedding earns its place when users already live somewhere else: a SharePoint intranet, a Teams channel, a Power BI dashboard they check every morning. Putting a canvas app onto a model-driven form is right for a genuinely different visual treatment of related data, and wrong as a way to avoid learning the form designer — a custom page is usually the better answer now. Skip iframe embedding into an external website unless every user is in the tenant, because that constraint is absolute and it's the first thing people discover after they've built it.

Configuration decisions

• Which host surface each app targets, because it determines auth, sizing and which capabilities survive.
• Whether the model-driven route uses an embedded canvas app or a custom page — custom pages avoid the three-per-form limit, the separate publish, and the read-only data context.
• Which column an embedded canvas app is bound to on the form: it must be one guaranteed to have a value, or the app won't refresh when form data changes.
• Whether the app is responsive with Scale to fit off, or fixed with it on. Getting this backwards is the usual cause of stray whitespace and scrollbars.
• How parameters reach the app, given they're read once at launch.

Gotchas

• Sharing is separate everywhere. An embedded canvas app has to be shared with the users of the host form, and "It looks like you don't have access to this app" is what they see when it hasn't been.
• Users also need read privileges on the CanvasApp Extended Metadata table. Without it, an imported solution loads the app from the source environment rather than the current one — a genuinely confusing symptom.
• Form field height is ignored by the embedded canvas app control. Height is derived from the app's aspect ratio relative to the available width, so height adjustments mean changing the aspect ratio, which requires tablet layout.
• The three-app-per-form limit counts enabled apps, not added ones. You can add more and enable three.
• A save on the model-driven form doesn't save anything in the embedded canvas app. Users assume it does, every time.

Consultant notes

• Ask where users actually work before choosing a surface. Teams and SharePoint embedding succeeds mostly because it removes a navigation step, and that's the whole benefit.
• For model-driven scenarios, default to custom pages and treat embedded canvas apps as the legacy path. Fewer limits, cleaner ALM, and no separate publish step to forget.
• Flag the same-tenant restriction in writing before anyone designs a customer-facing embed. If external users are in scope, that's Power Pages, not an iframe.
• Warn about the publish-separately behaviour explicitly. It's the most common "we deployed and nothing changed" call on embedded apps.

---

Revisit if embedded canvas apps gain Phone and Tablet support, or once custom pages fully cover the same scenarios.