Catch the Unforeseen: A Practical Guide to Power Apps OnError

Even the most carefully crafted app can encounter errors you didn't explicitly plan for. A user might type letters into a numeric field, a datasource may time out, or a calculation might receive an unexpected null value. The OnError property gives you a safety net: a central place to define what should happen when any unhandled error occurs, so you can show a friendly message, collect diagnostics, and keep your app from crashing silently.

This article uses a new example – a conference session check-in app – to walk through enabling the property, writing a custom error handler, and sending detailed logs to Power Apps Monitor.

The Scenario: Session Check-In App

Imagine you’re building a check-in kiosk for a conference. Attendees type their registration ID (a number) into a text input. The app looks up their name and marks them as present. If someone enters letters instead of digits, the Value function will throw an error. Without any error handling, the user sees a cryptic “Invalid arguments to the Value function” message and the app stops. With OnError, you can intercept that error, display a clear message on screen, and silently send the details to the development team.

Step 1 – Enable Formula‑Level Error Management

The OnError property (together with IfError and the FirstError record) became generally available in 2023. It is enabled by default in all new canvas apps. If you are working with an older app or a tenant that has not yet updated, you can enable it manually:

1. Open Power Apps Studio.
2. Go to Settings → General and look for Formula-level error management under the error-handling section.
3. Toggle it on if it is not already enabled.

In most current environments, the OnError property is visible on the App object without any manual configuration.

Step 2 – Build the App UI

Add these controls to the screen (you may rename them as you like, but the formulas below will refer to these names):

• A label titled “Conference Check‑In”. • A text‑input control named txtRegistrationId with Format set to Text (deliberately wrong – we want to test error handling). • A button named btnCheckIn with text “Check In”. Style it as a card by setting:

• BorderRadiusBottomLeft, BorderRadiusBottomRight, BorderRadiusTopLeft, BorderRadiusTopRight → 10
• DisabledBorderColor → DarkGray
• DisplayMode → DisplayMode.Disabled (so it looks inactive)
• Fill → White • Two labels: one for the Attendee Name result and one for the Status message. • A second text‑input named txtAttendeeName that will show the result. Its Default property will later point to a variable.

Feel free to add your own branding or additional fields – the key controls are the numeric input and the button.

Step 3 – Write the Calculation Logic (That Will Fail)

The check‑in process is simple: convert the registration ID text into a number, look up the attendee, and update the status. For this demo we’ll skip the actual datasource and just multiply the ID by a constant to simulate a lookup, then store the result in a variable.

In the OnSelect property of btnCheckIn, paste this code:

Set(
  varAttendee,
  Value(txtRegistrationId.Text)  // will fail when input is non‑numeric
);
Reset(txtAttendeeName)

Now set the Default property of txtAttendeeName to varAttendee. When the button is clicked, Value tries to parse txtRegistrationId.Text as a number. If the text is not numeric, an unhandled error is produced.

Step 4 – Handle the Error with OnError

The OnError property of the App object is the global handler. It fires for every error that is not caught by an IfError or a similar function. Inside it you have access to the FirstError record, which contains:

• FirstError.Message – the error text
• FirstError.Source – the control/property where the error first occurred
• FirstError.Observed – the control/property where the error was observed
• FirstError.Kind – an ErrorKind enum value (e.g., ErrorKind.Validation, ErrorKind.Div0, ErrorKind.Network, ErrorKind.NotFound). Use in conditions like If(FirstError.Kind = ErrorKind.Network, …)

You can show a notification and also send information to the Monitor using the Trace function.

Set the App.OnError property to the following:

Notify(
  Concatenate(
      "Check‑In Error: ",
      FirstError.Message,
      " | Observed at: ",
      FirstError.Observed,
      " | Source: ",
      FirstError.Source
  ),
  NotificationType.Error
);
Trace(
  "Unhandled Check‑In Error",
  TraceSeverity.Error,
  {
      Kind: FirstError.Kind,
      Message: FirstError.Message,
      Source: FirstError.Source,
      Observed: FirstError.Observed,
      Screen: App.ActiveScreen.Name,
      User: User().Email
  }
)

Step 5 – Generate the Error and See the Result

1. In the txtRegistrationId text input, type something that is not a number, for example ABC123.
2. Click Check In.
3. A red notification banner at the top of the screen displays the custom error message you built in Notify.
4. The app does not crash; the user sees a clear explanation and can correct their input.

To inspect the trace data, open Power Apps Monitor from the Advanced Tools menu (the bug icon at the top right). Run the failing action again, and you’ll see a new line with the severity Error and the details from your Trace call.

Send Errors to Application Insights (Optional)

If you have enabled Application Insights for your environment, Trace entries can be forwarded there automatically. This gives your team a persistent log of all unhandled errors, grouped by user, screen, and error kind. The setup is environment‑wide and does not require changes to your app’s code – just ensure that the “Send data to Application Insights” option is turned on in the Power Platform admin centre.

Security & Performance Considerations

• OnError runs for every unhandled error. Avoid placing heavy operations (like multiple Patch calls or large loops) inside the property. Use Trace and Notify only, which are lightweight.
• Do not use OnError for expected business logic. Use IfError where you can anticipate specific failure points (for example, a Patch that might conflict). Save OnError for truly unexpected cases.
• Trace messages are not delegation-safe, but this is irrelevant because Trace is executed client‑side and does not query data.
• User().Email requires that the user is signed in and the caller has the appropriate permissions. In a public kiosk app, this may be empty.

Common Mistakes and Troubleshooting

• Error still shows the default message Make sure Formula‑level error management is enabled. Without it, OnError is simply ignored.

• OnError does not fire Check whether the error is already caught by an IfError function further up the call stack. OnError only handles truly unhandled errors. Also verify that you’re not using OnError on a control – it only exists on the App object.

• Trace does not appear in Monitor Confirm that Monitor is actively recording. Click the Start recording button before reproducing the error. Also ensure that the TraceSeverity you used is not filtered out in the Monitor view.

• Notify banner shows but the app becomes sluggish Ensure you are not calling Trace repeatedly inside a loop or a timer. Keep the code inside OnError short.

Final Recommendation

The OnError property transforms error handling in Power Apps from a reactive guess‑and‑fix game into a proactive, observable system. By combining a friendly Notify with detailed Trace calls, you give both users and developers the information they need to resolve issues quickly.

For production apps, make OnError a standard part of your app template. Even if you cannot predict every edge case, you can guarantee that every error is recorded and that the user experience remains smooth.

References

• Original article: Power Apps OnError Property: Capture & Log Unexpected Errors
• Microsoft documentation: IfError function / FirstError
• Microsoft documentation: Trace function
• Microsoft documentation: Power Apps Monitor overview
• Microsoft documentation: Application Insights integration