Debugging Canvas Apps: Using the Power Apps Monitor Tool and Formula Errors to Fix Issues Fast

Introduction

You've built a canvas app. The screen looks great, the data connection is wired up, and you hit Play — and nothing works. A gallery shows no records. A button click does absolutely nothing. A form refuses to submit. You stare at the formula bar, the formula bar stares back at you, and you have no idea where to start.

This is the debugging phase, and every developer — from beginner to seasoned pro — spends real time here. The good news is that Power Apps gives you two powerful tools specifically designed to make this less painful: formula error indicators built directly into the editor, and the Monitor tool, a live diagnostic panel that shows you exactly what your app is doing at runtime. Together, they give you X-ray vision into your app. By the end of this lesson, you'll know how to read Power Apps' own error messages, use the Monitor tool to trace data calls and events, and systematically work through the most common failure modes in a canvas app.

What you'll learn:

• How Power Apps signals formula errors at design time and what those signals mean
• How to read and interpret the Monitor tool's event log during a live app session
• How to trace a failing data call from a button click all the way through to the connector
• How to use Notify() and Debug() techniques to surface hidden state
• A repeatable debugging workflow you can apply to any broken canvas app

---

Prerequisites

Before diving in, you should have:

• Basic familiarity with the Power Apps Studio canvas editor (opening an app, adding controls)
• At least one canvas app with a data source connected (SharePoint, Dataverse, or Excel will all work)
• A Power Apps license that lets you open Studio — a free developer plan is sufficient

You don't need to be a Power Fx expert. Part of what this lesson teaches is how to learn from error messages rather than needing to already know everything.

---

Understanding How Power Apps Signals Errors at Design Time

Before your app ever runs, Power Apps is constantly analyzing every formula you write. Think of it like a spell-checker that works on code instead of words — it reads your formula as you type and highlights problems immediately. This is called design-time validation, and it's your first line of defense.

The Red Underline and the Error Pane

When Power Apps detects a problem in a formula, it underlines the affected portion in red directly in the formula bar. You'll also notice a small red "X" badge appear on the control in the canvas, and the App Checker icon (a small shield or warning icon in the top toolbar) shows a count of active issues.

To see all errors in one place, click the App Checker icon. This opens a panel listing every formula error in your app, which control it's on, which property it's in (like OnSelect, Items, or Visible), and a plain-English explanation of what went wrong.

Let's say you have a gallery connected to a SharePoint list called ProjectTasks, and you accidentally typed the list name wrong in the Items property:

Filter(ProjectTask, Status = "Active")

Power Apps will immediately underline ProjectTask in red because it can't find a data source with that exact name. The App Checker will say something like: "Name isn't valid. 'ProjectTask' isn't recognized." This tells you precisely where to look — the name is wrong, not the logic.

Yellow Warnings vs. Red Errors

Not all signals are red. Yellow warnings mean Power Apps can run the formula, but something might not behave the way you expect. A common one is delegation warnings, which appear when you use a function like Filter() with a condition that the data source can't process on its side. Power Apps draws a yellow underline and a small caution triangle.

Important: A delegation warning doesn't mean your app is broken right now — it means it will fail silently at scale. If your SharePoint list has 500 rows and your formula can only process the first 500 locally, users with 501+ records will see incomplete data and no error message. Always treat delegation warnings as real bugs.

Reading the Error Message Carefully

New developers often dismiss error messages without reading them. Don't. Power Fx error messages are usually specific and actionable. Here are three common patterns:

Type mismatch: "Expected Text value" — you're passing a number where the formula needs text. Common fix: wrap the value in Text().

Invalid argument: "The function expects 2 arguments" — you called a function with the wrong number of parameters. Check the formula reference sidebar for the correct signature.

Unknown identifier: "Name isn't valid" — a control name, column name, or data source name is misspelled, or the data source hasn't been added yet.

---

Introducing the Monitor Tool

Design-time errors are caught before you run the app. But what about problems that only appear at runtime — a data source that returns no records, a patch that silently fails, a navigation that doesn't trigger? That's where the Monitor tool comes in.

The Monitor tool is a live diagnostic panel that records everything your app does while it's running: every formula evaluation, every network call to a connector, every user action, and every error that occurs — with timestamps, input/output data, and status codes. Think of it like the Network tab in a browser's developer tools, but purpose-built for Power Apps.

Opening the Monitor Tool

Inside Power Apps Studio, with your app open, go to the top menu and click Advanced Tools (in some versions this appears directly as Monitor in the left-hand toolbar, represented by a chart or magnifying glass icon). Select Open Monitor. This opens the Monitor panel in a separate browser tab or a side pane, depending on your version.

The Monitor panel is initially empty. It only captures events when an app session is actively running. You have two options:

1. Play the app from Studio — Click the Play button (triangle) in Studio. The Monitor tool will begin capturing events from your live preview session automatically.
2. Monitor a published app — In the Monitor panel, you'll see an option to generate a session link. Share that link with a user (or open it yourself), and Monitor will track that specific session even in the published app.

What the Monitor Log Shows You

Once the app is running, every action generates rows in the Monitor log. Each row contains:

• Time — when the event occurred
• Category — the type of event (e.g., UserAction, Connector, Formula)
• Control — which control triggered the event
• Property — which property was evaluated (e.g., OnSelect, Items)
• Result — whether it succeeded or failed
• Data — the actual input sent and output received (expandable JSON)

This is enormously powerful. When a button isn't working, you can click it in your running app, switch to Monitor, and see every single thing that happened — including calls to SharePoint, the exact JSON payload sent, and the exact response that came back.

---

Tracing a Real Failure: A Button That Doesn't Save

Let's walk through a concrete debugging scenario so you understand the workflow rather than just the tool.

The scenario: You have a canvas app for logging field service visits. There's a form connected to a SharePoint list called ServiceVisits. A "Save" button has this formula in its OnSelect property:

SubmitForm(ServiceForm);
Navigate(ConfirmationScreen, ScreenTransition.Fade)

When users tap Save, nothing happens. The form doesn't clear, no navigation occurs, no error message appears. This is the worst kind of failure — a silent one.

Step 1: Check the App Checker First

Before opening Monitor, always do a quick App Checker pass. In this case, it shows no errors — the formula is syntactically valid. So the problem is runtime behavior, not a formula typo.

Step 2: Open Monitor and Reproduce the Bug

Open the Monitor tool, start the app session, fill in the form fields, and click Save. Switch back to Monitor. You'll see a burst of new log entries. Look for any row with a red or orange Result indicator — that's your smoking gun.

Expand the row for SubmitForm. You might see something like:

Category: Connector
Operation: PatchRow
Result: Failed
Status Code: 403
Response: {"error": {"code": "Forbidden", "message": "Access denied..."}}

A 403 Forbidden response from the connector means the user doesn't have permission to write to the SharePoint list. The formula itself was perfectly fine — the issue is permissions, not code.

Tip: Status codes follow standard HTTP conventions. 403 = permissions. 404 = the list or column doesn't exist. 400 = bad data (often a required field is missing or the wrong data type). 500 = something went wrong on the server side.

Step 3: Check the Formula Chain

But what if Monitor shows SubmitForm succeeded, yet Navigate never fires? Expand both events. If SubmitForm shows Result: Success and the Navigate row doesn't exist at all, that's telling you the second command never executed.

This often happens because of a logic error in the formula chain. For example:

If(DataCardValue1.Text = "", Notify("Name is required"), 
   SubmitForm(ServiceForm); Navigate(ConfirmationScreen, ScreenTransition.Fade)
)

If the name field appears blank to Power Apps — even if it looks filled in on screen — the If branch routes to Notify and never reaches SubmitForm. Monitor would show a Notify event firing instead of SubmitForm.

---

Using Notify() as a Debugging Probe

The Monitor tool shows you what happened. But sometimes you also want to surface information inside the running app itself, especially when testing on a phone or sharing a test build with a colleague who doesn't have Monitor open.

Notify() is a function that displays a banner message at the top of the screen. It takes a text string and an optional notification type (NotificationType.Success, NotificationType.Warning, NotificationType.Error). You can use it as a debugging probe by temporarily injecting it into your formulas to report internal state.

For example, if you're not sure why a filter is returning no records, you can temporarily add:

Notify("Filter count: " & Text(CountRows(Filter(ServiceVisits, AssignedTo = User().Email))), NotificationType.Warning)

Drop this into the OnVisible property of a screen, run the app, and the banner will show you exactly how many rows matched the filter. If it says 0, you know the filter is the problem — and you can narrow it down from there.

Warning: Always remove Notify() debugging probes before publishing your app to production users. They're diagnostic tools, not features.

---

Reading Formula Errors at Runtime with IfError()

Sometimes a formula fails silently because there's no error handling around it. Power Fx has a function called IfError() that lets you catch errors and respond to them explicitly. You can use this both as a permanent defensive pattern and as a temporary debugging tool.

Here's the pattern:

IfError(
    Patch(ServiceVisits, Defaults(ServiceVisits), {
        Title: DataCardValue_Title.Text,
        AssignedTo: DataCardValue_Assigned.Text,
        VisitDate: DataCardValue_Date.SelectedDate
    }),
    Notify("Save failed: " & FirstError.Message, NotificationType.Error)
)

When Patch() fails, instead of silently doing nothing, this formula displays the actual error message from the connector. FirstError.Message is a built-in property that contains the human-readable description of whatever went wrong — the same message that appears in Monitor, but now surfaced directly to you (or a test user) in the app itself.

This pattern is so useful that you should consider making it a permanent part of your save operations, not just a debugging tool.

---

A Systematic Debugging Workflow

Random clicking around rarely fixes bugs faster than a methodical approach. Here's a repeatable workflow for any canvas app problem:

1. Describe the symptom precisely

Before touching anything, write down exactly what's broken: "The gallery on Screen2 shows no records when the app loads" or "The Save button on the entry form does nothing." Vague problem statements lead to random fixes.

2. Check the App Checker

Open the App Checker. Fix any red errors first — they prevent the app from running correctly regardless of anything else. Note any yellow delegation warnings that might be relevant to your symptom.

3. Isolate the problem to a control and property

Is it a display problem (gallery, label, text input)? Then the issue is likely in a Items, Text, or Default property. Is it a behavior problem (button, timer, form)? Then look at OnSelect, OnSuccess, OnFailure.

4. Open Monitor and reproduce

Run the app with Monitor open. Perform exactly the steps that trigger the bug. Then look at Monitor for:

• Any red/failed events
• Missing events (actions that should have fired but didn't)
• Unexpected 4xx/5xx status codes from connectors

5. Use Notify() to confirm assumptions

If Monitor shows a formula branch you didn't expect, use Notify() to print intermediate values and confirm what data the formula is actually seeing.

6. Fix one thing at a time

Change one formula, re-run, check Monitor again. Changing multiple things simultaneously means you won't know which change actually fixed the problem.

---

Hands-On Exercise

This exercise uses a SharePoint list, but you can adapt it to any data source.

Setup: Create a SharePoint list called TaskLog with columns: Title (text), Priority (choice: High/Medium/Low), DueDate (date), AssignedTo (person).

Build the following in a canvas app:

• A gallery on Screen1 showing all TaskLog items
• A button labeled "Add New" that navigates to Screen2
• Screen2 has a form for entering a new task and a "Save" button

Now intentionally break it three ways:

1. In the gallery's Items property, misspell the list name as TaskLogs
2. In the Save button's OnSelect, remove the semicolon between SubmitForm and Navigate
3. Remove your account from the SharePoint list's write permissions

Your debugging challenge:

• Use the App Checker to identify and fix the first error
• Use Monitor to trace the second error (a formula parse issue will prevent the button from doing both actions)
• Use Monitor + IfError() with Notify() to surface the third error's message

This exercise forces you to encounter the three major error categories — design-time formula errors, logic errors, and runtime connector errors — and use the right tool for each.

---

Common Mistakes & Troubleshooting

"Monitor shows nothing even though the app is running." Make sure you launched the app after opening Monitor, or that you used Monitor's session link feature. Monitor only captures events from the session that was started while it was active.

"App Checker shows zero errors but the app still doesn't work." App Checker only catches syntax and type errors. Logic errors — like filtering on the wrong column, or navigating to a hidden screen — are invisible to it. That's what Monitor is for.

"The Monitor Data column just shows [object Object]." Click the expand arrow on the row. The data is there in JSON format — it just starts collapsed. For connector calls, look for the responseBody field inside the expanded view.

"My Notify() debugging messages aren't appearing." Check that you didn't accidentally put the formula in OnStart of the App rather than OnVisible of the screen — OnStart fires before the screen renders, so banners might disappear. Also make sure Notify() is being reached: if it's inside an If() branch, the condition might be routing elsewhere.

"I fixed the formula and the error is still there." Power Apps Studio sometimes caches state. Try pressing Escape to exit Play mode, wait a moment, and press Play again. If the App Checker still shows a stale error, try closing and reopening the app.

---

Summary & Next Steps

Debugging isn't a sign that you wrote bad code — it's a normal, necessary part of building any app. What separates fast debuggers from slow ones isn't memorizing all the right formulas; it's knowing how to find information. Power Apps gives you two excellent tools for this: the App Checker catches problems before you run the app, and the Monitor tool gives you complete visibility into what happens when the app runs.

The workflow is always the same: describe the symptom, check design-time errors first, then use Monitor to trace runtime failures, and use Notify() and IfError() to surface hidden state. Work one change at a time, and verify with Monitor after each fix.

Here's what you can now do:

• Read and act on Power Apps formula error messages instead of guessing
• Open the Monitor tool, start a session, and interpret the event log
• Trace a failing connector call through to its HTTP status code
• Use IfError() and Notify() as diagnostic probes in your formulas
• Apply a systematic, repeatable debugging process to any broken canvas app

Next steps to build on this lesson:

• Error handling patterns — Learn how to use IfError(), IsError(), and Errors() as permanent, production-quality error handling rather than just debugging aids
• Performance troubleshooting — Use Monitor's timing data to identify slow connector calls and fix delegation issues that cause apps to feel sluggish
• Testing and co-presence — Learn how to use Monitor's session sharing to debug issues that only appear on a specific user's device or account