3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools

Monitor: A Real-Time Window Into App Execution

Monitor is Power Platform's built-in diagnostic tool for observing what a canvas or model-driven app is actually doing while it runs — not just what the formula bar or form definition says it should do. It's launched from the Power Apps maker portal (an app's details page > Monitor) or directly from Studio's Preview mode, and it attaches to a live session of the app, streaming events as the tester interacts with it in real time. This is the tool the blueprint names explicitly for "troubleshoot canvas and model-driven app issues" (3d), and it's the primary developer-facing alternative to guessing why a screen is slow or a value is wrong.

What Monitor Captures

Monitor records a structured, filterable, searchable timeline of everything happening inside a session:

• Formula evaluations — which control property fired, the formula that ran, and how long it took.
• Network and data calls — every request to a connector, the Dataverse Web API, or a cloud flow invocation, including request and response payloads and latency.
• Errors and delegation warnings — surfaced inline with the formula and control that triggered them, not just a generic error banner.
• Control and screen events — OnVisible, OnSelect, navigation, and other trigger firings in sequence.

Because entries are timestamped and taggable by control, a developer can isolate exactly which data call on which screen is adding several seconds to a load — information that's effectively invisible from the Studio canvas alone. Monitor sessions can be filtered by event type and searched by control or data source name, and individual sessions can be exported for offline analysis or shared with support.

Monitor for Canvas Apps vs. Model-Driven Apps

Model-driven apps additionally expose performance data through the browser's own Diagnostics overlay, opened via a keyboard shortcut inside a running form, which reports form-load phase timing — script load, data retrieval, rendering — a level of detail Monitor complements rather than replaces for model-driven scenarios.

Browser-Based Debugging Tools

For anything Monitor doesn't surface — raw JavaScript exceptions in a model-driven form script, a PCF component's rendering logic, or a Web API call's exact request or response body — developers fall back to the browser's own developer tools (F12):

• Console — surfaces uncaught JavaScript errors from Client API scripts and PCF components, plus any deliberate diagnostic logging a developer adds during development.
• Network tab — shows raw HTTP requests to the Dataverse Web API (/api/data/v9.x/...), including headers, status codes, and JSON bodies — essential for diagnosing a failed Xrm.WebApi call that Monitor logs only at a higher level.
• Sources tab — allows setting breakpoints directly inside deployed JavaScript web resources or a PCF component's bundled code, stepping through execution exactly as with any client-side web app.
• Application and Storage tabs — useful for inspecting cached tokens or local storage state in offline-capable canvas apps.

Because model-driven client scripts and PCF components run as ordinary JavaScript or TypeScript in the browser, they get the full benefit of standard web debugging — unlike Power Fx, which Monitor is purpose-built to interpret since it is not standard JavaScript the browser natively understands.

Correlating and Escalating

Every traced Dataverse Web API and Organization service call surfaces a correlation ID inside Monitor. When an issue can't be resolved from Monitor or browser tools alone — a suspected platform throttling issue, an intermittent server-side error — that correlation ID is the piece of evidence to hand to Microsoft support or include in a Power Platform admin center service request, letting engineers trace the exact server-side request without needing to reproduce the client-side steps. Combining Monitor's structured event timeline with browser dev tools' raw request and response detail, and a correlation ID for anything server-side, is the complete PL-400 troubleshooting toolkit for both app types.

Choosing the Right Tool for the Symptom

A useful exam heuristic is to match the symptom to the tool rather than defaulting to one:

• "A screen or form is slow, but nothing is technically broken" — start with Monitor to see which formula, data call, or form-load phase is consuming the time.
• "Something throws an error message I don't understand" — check Monitor for a Power Fx or delegation-related error first; check the browser Console for a JavaScript or PCF exception if the issue is in a model-driven script or component.
• "A Web API call returns unexpected data or an HTTP error code" — use the browser Network tab to inspect the exact request and response body, since Monitor's summary view may not show every field.
• "The issue only happens in production, or intermittently, and can't be reproduced locally" — capture the correlation ID from Monitor and escalate through the Power Platform admin center or Microsoft support rather than continuing to guess client-side.

Treating these as a decision tree, rather than reaching for the browser console out of habit, keeps troubleshooting fast and is consistent with how the PL-400 blueprint frames this sub-topic: know which tool answers which question.