What it does

Two related but separately configured things. Canvas apps take an Application Insights connection string in app settings and emit their own session, page view and trace telemetry. Model-driven apps and Dataverse get telemetry exported to an Application Insights resource by an admin, and that export is a managed environments feature. Both land in your own Azure resource, in the standard Application Insights schema.

Key facts

• Canvas setup is a connection string pasted onto the App object in Studio, then save and publish. Nothing else.
• The tenant setting Canvas app insights has to be on (Tenant settings > Canvas app insights) or makers see nothing.
• Events only flow from the published app. Previewing in Studio sends nothing.
• The Trace() Power Fx function writes custom events at three severities: Information, Warning, Error. Custom data lands in customDimensions.
• Default dimensions on every canvas event: ms-appId, ms-appname, ms-appSessionId, ms-tenantID, ms-environmentId, userId, sessionId, ms-isTest, ms-currentScreenName, ms-targetScreenName.
• The PowerAppsClient.PublishedApp.SessionLoadSummary custom event is the useful one for performance: successfulAppLaunch, unsuccessfulReason, appLoadResult (optimal / other), appLoadNonOptimalReason, timeToAppInteractive and timeToAppFullLoad in milliseconds.
• The x-ms-app-load-state request header on dependencies tells you whether an HTTP call contributed to full load — TTFL if it did, PostTTFL if not.
• Export data to Azure Application Insights for model-driven and Dataverse telemetry is listed as a managed environments capability. cloud_RoleInstance is set to CDS Data Export so you can separate it from other events.
• client_IP is always 0.0.0.0 for privacy compliance. City, state and country fields are still populated from it.
• Two experimental features exist: Pass errors to Azure Application Insights (unhandled Power Fx errors into the traces table as "Unhandled error", severity 3) and correlation tracing (W3C trace context across app and custom connector calls).

When to use / skip

Instrument anything that matters to the business and anything with more than about fifty users. The session load summary alone justifies it — an app open success rate by day, and a 75th percentile time-to-interactive, will tell you more about whether last month's release helped than any amount of anecdote. Skip it for a departmental app with twelve users where the users sit near you; you'll hear about problems faster than the telemetry will. Also skip it if nobody in the client's organisation owns an Azure subscription and will pay for log ingestion, because an unmonitored Application Insights resource is just a bill.

Configuration decisions

• Whether all apps share one Application Insights resource or each gets its own. One resource with ms-appId filtering is usually right, and cheaper.
• Whether the connection string is set through an environment variable so it differs between dev, UAT and production — hardcoding it means test traffic pollutes production telemetry.
• What gets a Trace() call. Screen navigation and error branches are the minimum; business events are what makes the data worth having.
• Whether the experimental error-passing and correlation tracing settings are turned on, accepting the "not for production" caveat and the extra ingestion cost.
• Whether model-driven and Dataverse export is in scope, which drags managed environments into the design.

Gotchas

• Telemetry crosses tenant boundaries. A connection string points wherever it points, including an Application Insights resource in someone else's tenant, and the platform doesn't stop it. Microsoft flags this specifically for imported .msapp files — open an imported app and check the connection string before you publish.
• Nothing appears until the tenant setting is on. Makers spend an afternoon on this before someone thinks to ask an admin.
• Nothing appears from Studio preview. Second afternoon.
• Session load summary fields are accurate for canvas apps in a browser. They aren't available for Power Apps mobile and may be unreliable for custom pages.
• Offline player events aren't recorded at all, and mobile events are lost when the app is suspended. Any offline-first app has a telemetry blind spot by design.
• Correlation tracing only works with custom connectors, and only captures the far side if that service is itself wired to Application Insights.
• If you log user names or emails through Trace(), that's personal data in an Azure log store with its own retention. Microsoft points at the Trust Center; your client's DPO should see the design.

Consultant notes

• Make instrumentation part of the definition of done rather than a post-go-live project. Retro-fitting Trace() calls across forty screens is a job nobody funds.
• Give the client the three queries that matter — app open success rate by day, 75th percentile load time, unsuccessful sessions by reason — as a saved workbook. A dashboard they can open beats a capability they've been told about.
• Cost is the objection you'll get. Ingestion is billed on the Azure side and unhandled-error passing plus correlation tracing both increase it; say so before it appears on a bill.
• Flag the cross-tenant connection string behaviour to the security team explicitly. It's the one genuinely surprising thing in this feature.

---

Worth another pass when the experimental error and correlation tracing settings go GA, or if mobile session telemetry gets filled in.