Power Apps Error Handling: How to Catch, Handle, and Log Errors

Error handling in Power Apps is one of those topics everyone knows they should care about… but very few people actually implement well. Most apps rely on a red error bar, maybe a Notify(), and then hope the user doesn’t notice when something quietly fails like below.

BTW - How is it that users manage to not see that big pink bar? It happens so often and breaks my brain, Power Apps errors are often not secrets.

Anyway, the built in Power Apps error handling works right up until your app is in production, users are clicking fast, data isn’t perfect, permissions change, or a flow decides to fail on a random Tuesday afternoon. I don't know why it is always Tuesday, but it is.

If you are building Power Apps that real people depend on, you need a real error handling strategy. Not something fancy. Not something over-engineered. Just something... that works.

This post walks you through a practical approach to Power Apps error handling, by showing you three tools every app builder should know:

1. IfError to catch errors you expect

2. OnError to catch errors you didn’t expect

3. And how to add logging so you don’t lose errors if they happen

Why error handling in Power Apps matters

Power Apps will happily let your app continue running even when something fails. A Patch can fail. A flow can fail. A connector call can fail. Sometimes you get a red bar. Sometimes you get nothing. Either way, your app often keeps going like everything is fine.

One of the biggest mistakes I see here, is when you Patch and Navigate. If you just separate the two functions with a ; then Power Apps will take them to the next screen no matter how loudly Patch screams.

Below is the most common way we see it written OnSelect for a button.

That’s the dangerous part. Without error handling:

• Users don’t know their action failed

• Data doesn’t save the way you think it did

• You have no idea something broke until someone emails you

• Reproducing bugs becomes guesswork

Good error handling isn’t about preventing errors. It’s about detecting them, responding appropriately, and giving yourself enough information to fix them later. (But of course, writing formulas without errors is always a good idea also)

Catching expected errors with IfError

The first layer of Power Apps error handling should always be IfError.

IfError is designed for situations where you already know something might fail. Common examples include:

• Patch operations

• Collect or Remove calls

• Submitting data to SharePoint or Dataverse

• Calling a Power Automate flow

• Writing to a data source with required columns or permissions

IfError does not fix anything, it simply gives you control when something goes wrong. Check out the example below:

This tries a Patch. If the Patch fails then it triggers a variable that makes a giant error screen shows up and it uses a User Defined Function to save the error details to your error logging table. If the Patch works, it navigates to the next screen as expected.

The key idea is this: if you can predict that an operation might fail, wrap it in IfError and decide what should happen next.

That might mean:

• Showing a friendly message to the user

• Logging the error

• Preventing the user from navigating away

• Retrying the operation

What you should not do is let the app fail silently and hope the red bar is enough. You want to create a Handled Error. This means that instead of letting Power Apps just fail and deal with it, you say if this error happens, then handle it like so.

Check out the video on the Power FX IfError function to see in detail how to use the function.

Catching unexpected errors with OnError

Even if you are disciplined about using IfError, you will miss things and end up with UnHandled Errors. Large apps have lots of formulas, screens, controls, and connectors. Some errors only show up at runtime. Others happen before your variables finish loading.

That’s where the Power Apps property App.OnError comes in.

OnError is global. It fires when an unhandled error occurs. Think of it as a safety net, not a replacement for IfError.

This is especially useful for things like:

• Runtime formula errors

• Connector timing issues

• Noisy errors from connectors like Office 365 profile calls that briefly fail and then succeed

A great real-world example is Office 365 user profile calls. Many apps briefly throw an error while profile data is loading, even though everything works a moment later. UGH. Wrapping every single call in IfError is messy and repetitive. Using OnError gives you a single place to suppress or handle that noise intelligently.

The important rule here is intent. OnError is not for ignoring real failures. It is for catching things you didn’t plan for or filtering out errors that are not actionable.

Important: OnError is not a function, it is a property of the App object that runs when an Error occurs. As seen above, what you do inside of there is up to you. You can do everything from reinvent the error message screen, to logging, or even suppressing. The world is your oyster.

To see OnError in action check out this video Handling the unexpected errors in Power Apps with OnError.

Do you have errors in your Power Apps and need a helping hand? Hit the Contact button and let us know. We are happy to give you a nudge, hop on a screen share, or do the whole project.

Understanding Errors and FirstError

Power Apps gives you two related tools for viewing error details that often get mixed up: Errors() and FirstError.

Errors() is tied to a specific data source. It returns a table of errors from the most recent operation against that source. This is useful when you know exactly what failed and want detailed information. Use it with IfError.

FirstError is global. It does not require a data source. It works with App.OnError and in situations where you don’t know what just failed, only that something did.

Understanding this distinction alone clears up a lot of confusion around Power Apps error handling. Each is shown in the related video for IfError or OnError. FirstError has the most details but sadly doesn't work with IfError.

Logging errors so you don’t lose them

Catching errors is only half the job. If you never see them again, you’re still guessing. This is where logging comes in.

A simple SharePoint list is more than enough for most apps. You don’t need a monitoring platform. You don’t need dashboards on day one. You just need a place to write errors down.

At a minimum, logging should capture:

• What app the error came from

• What screen it happened on

• What control or action triggered it

• The error message itself

SharePoint already tracks who created the record and when, so you get user and timestamp data for free.

Once you are logging errors, notifications become optional. An email when something critical fails can be helpful, but the real value is having a history you can review later.

If you want to get real fancy, then check this out. An example of using a User Defined Function (UDF) for the error logging:

By using a UDF you make the error handling easy to reuse throughout the app. Also, in this example, it has logic to suppress multiple error messages. Not saying suppression is a good idea, but sometimes it is a necessary evil until you get things sorted.

In the third video of the series, I show how to log errors to SharePoint and optionally send an Outlook email, using a reusable User Defined Function so the same logic works from IfError, OnError, or both. Video: Power Apps Error Logging and Notifications

Why this layered approach works

The mistake most people make is looking for a single “error handling solution” in Power Apps. There isn’t one.

Instead, think in layers:

• IfError for expected failures

• OnError for unexpected or noisy failures

• Logging so nothing disappears

Each layer does one job. Together, they make your apps more reliable, easier to debug, and far less stressful to support.

Final thoughts

Power Apps error handling doesn’t have to be complicated, but it does have to be intentional. If you only rely on the red error bar, your app is lying to you. If you never log errors, you are flying blind.

The good news is that a small amount of structure goes a long way. Once you start thinking about failure paths instead of just success paths, the quality of your apps improves fast.

If you want to see these patterns implemented step by step, there are three companion videos that walk through use the links to the specific videos above, or you can use the whole Power Apps Error Handling playlist.

That’s how you stop guessing, stop losing errors, and start building Power Apps that behave like real production apps.