Power Apps Error Handling

The difference between a flaky app and a solid one is usually error handling. A Patch to SharePoint can fail for a dozen reasons. A lookup misses. A conversion throws. A required field is blank. Another user claims the same unique value half a second before you do. By default those failures surface as ugly banners or silent blanks.

This page covers the patterns that keep it under control, ending with the one most guides skip: what to do when two people save at the same time.

Before you start: turn the feature on

Formula-level error management is on by default for new apps, but older apps may have it disabled. If it is off, IfError and IsError will not behave the way anything on this page describes, and errors come back as blank values instead.

How errors travel

Errors propagate through formulas the way #DIV/0! propagates through a spreadsheet. An error input produces an error output, all the way up the chain.

Three functions are designed to intercept an error instead of passing it along: IfError, IsError, and IsBlankOrError. Everything else forwards it. You are not catching exceptions at a call site, you are putting a filter somewhere in a pipe.

The four building blocks

IsError: did it fail?

IfError: recover with a fallback

IsBlankOrError: the usual real-world check

Errors(): per-field messages after a failed write

Use FirstError.Message when you want one line for a notification. Use Errors(DataSource) when several fields failed at once and the user needs to see all of them.

Watch the argument count on IfError

This trips up nearly everyone. The signature is:

Patch with an error check

Capture the result of a Patch and branch on it. This is the single most valuable pattern on this page.

Note the property names. Classic and modern text inputs both expose .Text, not .Value. A ComboBox exposes .Selected for a single record and .SelectedItems for multi-select. Getting this wrong is the most common reason a Patch fails with a type error rather than a data error.

Validate before you write

Cheaper than handling a failure is preventing it. Short-circuit on invalid input with a chained If before the Patch ever runs.

Validation prevents mistakes the user can fix. It cannot prevent failures that depend on what other users are doing at the same moment. That is the next section.

Forms: OnSuccess and OnFailure

If you use a Form control with SubmitForm, do not wrap the submit in IfError for ordinary error handling. The form has dedicated behavior properties.

Gate the submit on frmItem.Valid so required-field errors show inline before you attempt the write.

The form also exposes frmItem.ErrorKind, which gives you the same enum value as FirstError.Kind. Use it in OnFailure when you want to react differently to a permission failure than to a conflict. The one time you do wrap SubmitForm in IfError is when you intend to retry the submit yourself. That is the concurrency case below.

Concurrency: when two users save at once

This is the failure mode that validation cannot catch and that most tutorials never mention.

The scenario

You have a SharePoint list with a column that must be unique. Maybe it is a case key like FY26-1043, built from a fiscal year plus an incrementing number. You turned on Enforce unique values on the column, which is the right call.

Your app computes the next number by reading the highest existing one and adding 1. Two users open the form within a few seconds of each other. Both read 1042. Both compute 1043. The first save wins. The second one gets rejected by SharePoint with a constraint violation, and unless you handle it, the user sees a generic red banner and loses their work.

Why the constraint is doing the real work

It is worth being clear about what is protecting your data here. It is not your formula. Any client-side "read the max, add one" is racy by construction, because there is a window between the read and the write during which anyone else can write.

Getting the next number correctly

Two things go wrong in the version of this most people write.

The delegable version sorts on the number itself and takes the first row:

Sort and Filter both delegate against SharePoint provided case_id and FY are indexed columns. First then takes the top of the sorted result rather than the top of an arbitrary page. Coalesce handles the first record of a new fiscal year, where the filter returns nothing. Index both columns in list settings. Without the index, SharePoint will refuse to sort past 5,000 items and you are back to a truncated page.

The gotcha that breaks the naive retry

Here is the trap. A common retry looks like this:

There are two ways around it.

Option A: Patch directly, skip the form for the key

The cleanest fix is to not depend on a control's value at all. Compute the key inside the formula, so the retry uses a value you control directly.

The nested With matters. A With binding is evaluated once, so reusing wNextId after the Refresh would give you the stale number. The inner With re-reads after the refresh. One retry is the right number: if two collisions happen back to back you have a load problem, not a race, and hammering SharePoint will make it worse.

Option B: keep the form, retry on a timer

If you need the form control for its validation and card layout, break the retry across a repaint using a timer. The timer tick gives the control tree a chance to pick up the new variable before the second submit.

The locRetrying guard is what stops an infinite loop. Without it, a second failure re-enters OnFailure, restarts the timer, and you have built a retry storm. Because the timer does span a repaint, this is also the version where a loading overlay actually works. Bind the overlay's Visible to locRetrying.

Confirm the ErrorKind in your own tenant

ConstraintViolated (8) is what SharePoint returns for a unique-column rejection in most cases, but the connector can surface a conflict as Conflict (6) or Validation (11) depending on the failure path and the column type. Do not guess. Drop a temporary label on the screen and set its Text to frmCase.ErrorKind, force a duplicate by hand, and read what you actually get. It takes two minutes and saves an afternoon.

When to stop doing this in the app

If the key genuinely matters (it appears on a document or gets quoted to a customer), move the generation server-side. A Power Automate flow triggered by the app is a single writer: it reads the max, writes the record, and returns the key, with no window for another client to slip in. Simplest of all: if you do not truly need a formatted key, SharePoint's built-in ID column is already unique, already generated server-side, and already free.

Coalesce for safe defaults

Many "errors" are really just blanks propagating. Coalesce returns the first non-blank value, which kills a whole class of downstream failures.

Note that Coalesce handles blank, not error. For an expression that can throw, wrap it: IfError(Value(txt.Text), 0).

App.OnError: the global net

App.OnError runs for every unhandled error in the app. It cannot fix or replace the error, because by the time it runs the error has already propagated through your formulas. What it can do is log and control how the failure is reported.

Leaving out the Error(FirstError) line suppresses the banner entirely, which is occasionally what you want and usually is not. Silent failure is worse than an ugly banner. To suppress one specific noisy kind and keep everything else:

Custom errors

You can raise your own errors and catch them like any other.

Use values above 1000 for custom kinds so you never collide with a system value Microsoft adds later.

Errors inside ForAll

ForAll does not stop at the first error. Every iteration runs and the errors accumulate, which is usually what you want for a bulk operation but surprises people the first time.

AllErrors is the table form of FirstError and is available in the same scopes.

ErrorKind reference

Every value in the enum, with what actually triggers it in practice.

Kinds worth branching on specifically: 6, 8, and 11 for write conflicts and constraints; 3, 4, 5, and 19 for permissions; and 23 for transient network failures.

Rules of thumb

• Wrap anything that can throw: Patch, Value(), ParseJSON, and LookUp on a maybe-missing row are the usual suspects.
• Confirm formula-level error management is on before you rely on any of this.
• Branch on FirstError.Kind, not on FirstError.Message. Message text is locale dependent and Microsoft rewrites it without warning.
• Show a message the user can act on. Include the underlying message rather than a bare "Error."
• Prefer a validation guard over a recovery path. An error you prevent never needs a message.
• Never assume a client-computed unique value is safe. Enforce it at the data source and treat your formula as recovery.
• Retry once, not in a loop, and always with a guard variable.
• Remember that Set() does not propagate to control properties within the same behavior formula. Break the chain with a timer or bypass the control entirely.
• Remember that a loading indicator toggled and untoggled inside one behavior formula never renders.