Power Apps Exception Handling: IfError, Errors(), Patch Error Handling and App.OnError

A facilities manager asked me why her request app said nothing when a save failed. Users typed 99 hours into a field that only allows 0 to 40, saw a vague red banner for two seconds and assumed the record was saved.

The app wasn’t broken. It just had no exception handling, so Power Apps showed its default message and moved on. Worse, a blank required Title went through without any error at all.

In this tutorial, we’ll add power apps exception handling to a real Patch form: IfError, IsError and IsBlankOrError for formulas, Errors() for the data source, a custom Error() for your own rules and App.OnError as a safety net.

Quick answer: wrap every Patch in IfError(Patch(...), Notify("Save failed: " & FirstError.Message, NotificationType.Error), Notify("Saved", NotificationType.Success)). The second argument runs only when the save fails, and FirstError.Message holds the real reason. Check required fields yourself before the Patch, and set App.OnError for anything you didn’t wrap.

Build the Demo App Step by Step

Every example runs in my Service Desk Demo canvas app on a SharePoint site called /sites/SPGuides. If you’ve never connected an app to a list, my guide to creating a canvas app from a SharePoint list covers it in more depth.

For this post I added a small throwaway list called SPGDemo Cleanup Items. It has a required Title column and a Number column called Hours with a minimum of 0 and a maximum of 40. Those two rules are what we’ll break on purpose.

Step 1: Start a new app. Go to make.powerapps.com and select Start with design on the Home page.

Step 2: Create a blank canvas app. Select Create from blank. A canvas app is one where you place every control yourself.

Step 3: Pick the Tablet layout. Choose Tablet and select Create. Power Apps Studio, the app editor, opens.

Step 4: Add the SharePoint connector. Select Add data, search for SharePoint and pick the SharePoint connector.

Step 5: Connect to the site. Paste your site URL and select Connect.

Step 6: Choose the list. My screenshot shows Service Requests, the list my other demos use. For this post, check SPGDemo Cleanup Items instead and select Connect. The list is now a data source, which is just a place the app reads and writes records.

Step 7: Add the screen and controls. Select New screen > Blank, then click the screen’s name in the Properties pane to rename it (mine is scrErrors). From Insert, add two Text inputs (txtErTitle and txtErHours), three buttons and a few labels.

To set a property, select the control, pick the property in the dropdown on the left of the fx formula bar, then type the formula. Run the app with Play at the top right, or hold Alt and click a button. Press Ctrl+S to save.

How Exception Handling Works in Power Apps: IfError, IsError and IsBlankOrError

An exception in Power Apps is an error value. A formula that divides by zero or turns “abc” into a number doesn’t crash the app. It returns an error, and the error travels into whatever uses that result.

Three functions deal with it. IfError swaps an error for a fallback, IsError tells you whether a value is an error, and IsBlankOrError is true for a blank value or an error. I put these five formulas in labels on scrErrors:

IfError(1/0, -1)
IsError(1/0)
IfError(Value("abc"), 0)
IsError(Value(txtErHours.Text))
IsBlankOrError(Value(txtErHours.Text))

With 8 in the Hours box, they returned -1, true, 0, false and false. Then I typed abc into Hours, and the last two flipped to true:

Value(“abc”) can’t make a number, so it returns an error. IfError(Value(“abc”), 0) catches it and gives 0 instead, which is handy for labels and totals.

The difference between the last two shows up on an empty box. With Hours cleared, IsError was false because Value(“”) is blank, not an error, while IsBlankOrError was true. Use IsBlankOrError when “nothing typed” should fail the check too.

Note: these functions need the Formula-level error management setting. It’s on in new apps; if someone turned it off in an older app (Settings > Updates > Retired), Microsoft says the functions won’t work correctly.

Power Apps Patch Function Error Handling

Patch is where exception handling pays off, because the data source can say no. If Patch itself is new to you, start with my Power Apps Patch function examples. Here’s the Save button’s OnSelect, a Patch that creates a new item, wrapped in IfError:

IfError(
    Patch('SPGDemo Cleanup Items', Defaults('SPGDemo Cleanup Items'),
        {Title: txtErTitle.Text, Hours: Value(txtErHours.Text)}
    ),
    Notify("Save failed: " & FirstError.Message, NotificationType.Error),
    Notify("Saved: " & txtErTitle.Text, NotificationType.Success)
)

IfError takes pairs. The first argument is the thing to try (the Patch). The second runs only if that returns an error. The last argument is the default result, which runs only when nothing failed, so it’s the right place for a success message.

Inside the second argument, FirstError is a record about what went wrong. Its Message is meant for end users, and Source names the control and property. The banners come from the Notify function in Power Apps.

Test 1: A Value the List Rejects

I typed “Printer toner” with Hours 99 and clicked Save with IfError. SharePoint refused it because Hours only allows 0 to 40, and my red banner showed the real reason:

The full text was “Save failed: Network error when using Patch function: [SPGDemo Cleanup Items] Value must be between 0 and 40”. Don’t let the word “network” fool you. The prefix is generic, and the useful part is the list rule at the end.

Nothing was saved. The two labels at the bottom read the data source’s error table with the Errors() function:

CountRows(Errors('SPGDemo Cleanup Items'))
Coalesce(First(Errors('SPGDemo Cleanup Items')).Message, "(none)")

They showed 1 error and the message “Value must be between 0 and 40”. Errors() returns a table with Record, Column, Message and Error columns, so it’s useful on a form screen where you want the message to stay visible after the banner fades.

Test 2: A Good Save Clears Errors()

Same title, Hours changed to 6. The green banner read “Saved: Printer toner”, the item was created and the error count went back to 0:

That matches Microsoft’s description: the next data function on the same source clears the old error information. So read Errors() right after the Patch, not on some later screen.

Test 3: Bad Input Caught Before the Server

This time Hours was abc. The banner read “Save failed: The value ‘abc’ cannot be converted to a number.” and Errors() stayed at 0:

Value() failed inside the app, so the Patch never reached SharePoint and the list had nothing to report. That’s why I don’t rely on Errors() alone. The same text-to-number problem shows up with Dataverse too, as my post on patching a Dataverse number field explains.

Back in edit mode, Studio also put a red x on the button. Hover it to see the runtime error, or select it to jump to the formula.

What Happens Without IfError?

The middle button runs the exact same Patch with no IfError. With Hours 99, Power Apps still caught the failure, but it showed its default banner:

It read “Network error when using Patch function: [SPGDemo Cleanup Items] Value must be between 0 and 40”, with no “Save failed” and no success message when it works. Errors() still showed 1. You get a message, but you can’t control the wording or run anything else.

Important: in a chain like Patch(...); Patch(...), the second Patch runs even when the first fails. Wrap them in one IfError to stop at the first failure. The same applies when you patch a collection to a SharePoint list.

Validate Before You Patch: The Required Title Gotcha

I left Title empty, kept Hours at 8 and clicked Save with IfError. I expected an error because Title is a required column. Instead, I got a green “Saved:” banner:

The item count went from 2 to 3, and SharePoint stored the item with an empty Title. Patch did not enforce the required column when I passed empty text, so IfError had nothing to catch.

Exception handling only catches what fails. For required fields, check the value in the app before you call Patch. My Power Apps form validation examples show more checks you can run first.

Throw Your Own Error With Error()

For your own rules, create an error with the Error() function and handle it in the same IfError. This is the OnSelect of the third button:

IfError(
    If(Len(txtErTitle.Text) < 5,
        Error({Kind: ErrorKind.Validation, Message: "Title needs at least 5 characters"}),
        Notify("Title OK", NotificationType.Success)
    ),
    Notify(FirstError.Message, NotificationType.Warning)
)

With the title VPN, the button showed a yellow “Title needs at least 5 characters” banner:

Error() needs a Kind; ErrorKind.Validation fits a rule like this one. Because the If() returns an error, IfError runs its second argument and FirstError.Message is my own text.

An empty title fails this check too, because Len(“”) is 0. In a real app, I put the Patch where Notify(“Title OK”) sits, so the save only happens after the rule passes. If you want the button to run several actions in one OnSelect, chain them inside that branch.

Catch Everything Else With App.OnError

You won’t wrap every formula in IfError. App.OnError runs whenever an error isn’t handled anywhere in the app, and it replaces the default banner. Select App at the top of the Tree view, pick OnError in the property dropdown and type:

Notify("Something went wrong: " & FirstError.Message & " (" & FirstError.Source & ")", NotificationType.Error)

Then I clicked Save without IfError with “Desk lamp” and Hours 45. My OnError banner replaced the default one:

It ended with (btnErPlain.OnSelect). FirstError.Source names the control and property where the error started, which saves a lot of hunting in a big app.

Note: OnError only controls how an error is reported. It can’t replace the value the way IfError can. To log errors and keep the default banner, Microsoft suggests Trace() followed by Error(FirstError). I removed my demo OnError after the test.

Which Error Handling Tool Should You Use?

Situation	Use
Replace a bad value in a label or calculation	IfError(value, fallback)
Check input before using it	IsError() or IsBlankOrError()
Save with Patch and tell the user what happened	IfError(Patch(...), Notify(FirstError.Message), Notify("Saved"))
Show the data source’s message on the screen	First(Errors(list)).Message
Your own business rule	Error({Kind: ErrorKind.Validation, Message: ...})
Anything you didn’t wrap	App.OnError

Common Errors and How to Fix Them

• Patch says “Saved” but the required field is empty. Patch didn’t block an empty Title in my test. Check required fields with IsBlank or Error() before the Patch.
• “Network error when using Patch function” on a good connection. Read the end of the message. In my test, it was the Hours column’s 0-40 rule, not the network.
• Errors() shows 0 after a failed save. The error happened in the app (Value(“abc”)), so the list never saw the request. Use FirstError.Message from IfError instead.
• The second Patch runs after the first one failed. Chained formulas keep going. Put both Patch calls inside one IfError.
• IfError, IsError or Error() don’t behave as documented. Check that Formula-level error management isn’t turned off under Settings > Updates > Retired.

For more Power Apps examples, browse the Power Apps tutorials hub, or build apps like this one with me in our Power Apps training course.

If you’re working on saves and errors, these tutorials help next:

• Power Apps Patch Error: The type of this argument ‘Attributes’ does not match the expected type ‘Record’. Found type ‘Text’
• You don’t have permission to view this data error in Power Apps
• How to Patch Gallery Items in Power Apps? (Single & Bulk)
• Power Apps LastSubmit: Get the Submitted Record and New ID After SubmitForm

Frequently Asked Questions