
SharePoint & PowerApps MVP - SharePoint, O365, Flow, Power Apps consulting & Training
In a clear and practical YouTube demonstration, Shane Young [MVP] explores global error handling in Power Apps by using the OnError property of the app. The video walks viewers through how the App.OnError event and related functions can catch unexpected runtime problems and help makers respond without disrupting the user experience. As a result, developers can turn raw failures into readable messages or automated recovery steps. This article summarizes the demonstration and highlights tradeoffs, challenges, and recommended approaches.
Shane explains that OnError acts as a global safety net for canvas apps built with Power Fx. Rather than handling each predictable problem with local checks like IfError or IsError, developers assign a formula to App.OnError so the app can react when any unhandled error occurs. Consequently, this reduces duplicated logic across screens and centralizes recovery behavior, which is particularly useful in larger apps.
Moreover, the video notes that many of the common failures come from data operations such as Patch, Collect, Remove, Update, and SubmitForm. Because those actions can fail due to network issues, permission problems, or connector errors, a global handler lets the app either suppress default dialogs or show a tailored message. Therefore, the user experience improves and support teams can get clearer signals about what went wrong.
Shane’s runtime demo covers several practical scenarios and timestamps are provided in the original video to jump to specific topics. Early in the video, he shows the basic setup for the OnError property and then reproduces an Office365Users connector issue to illustrate how the handler captures and surfaces the error. He also walks through how to display error text on a label using the first returned error message from the Errors function.
Next, the presentation demonstrates two important patterns: suppressing all errors and selectively suppressing only certain errors. For total suppression, the handler can swallow errors and show a generic notice, while selective handling evaluates the error type and responds only when needed. Finally, Shane inspects the structure of FirstError outputs, which provide details like Message and Kind so makers can make nuanced decisions in the handler.
Using a global handler brings clear benefits, yet it requires careful tradeoffs. On one hand, centralized error handling reduces repetitive code and standardizes user messaging, which is helpful in enterprise apps. On the other hand, it can obscure the context of where an error originated unless the handler logs additional metadata or attaches contextual tags to each operation.
Furthermore, choosing between suppressing all errors and selectively handling them involves weighing user trust against noise reduction. Suppressing every error may prevent frightening system pop-ups, but it risks hiding critical issues that need immediate attention. Conversely, granular handling increases complexity and maintenance overhead because each predictable failure path still needs its own logic or flagging mechanism.
Shane points out several practical challenges that developers should expect. For example, distinguishing between transient network issues and permanent permission errors can be hard because connectors sometimes return similar error shapes. In addition, Connection.Connected can misreport status in offline scenarios, which complicates automated retry strategies.
Another limitation is the performance and usability tradeoff when logging every error centrally: too much logging can increase app latency and storage costs, while too little logging reduces actionable insights for support teams. Therefore, teams must balance the level of telemetry they collect with responsiveness and user privacy requirements.
Based on the video’s guidance, several practical best practices emerge. First, use App.OnError to provide a consistent user message and to avoid raw system dialogs, and then supplement it with targeted error checks in sensitive flows. Second, use the fields from FirstError and Errors to decide whether to retry, log, or show a user-friendly message, so handlers remain informative without exposing raw system text.
Finally, implement lightweight logging that captures context like the screen name and operation type, and then aggregate important issues for follow-up. This approach gives teams the ability to act on recurring problems without cluttering each user session with excessive telemetry.
Shane Young’s video offers a practical, hands-on look at how OnError strengthens Power Apps reliability. He clearly shows how the global handler and FirstError outputs can improve user experience and simplify maintenance, while also noting the tradeoffs and pitfalls to avoid. Overall, adopting a thoughtful global error strategy helps teams create more resilient apps, provided they balance suppression with visibility and handle context carefully.
Power Apps OnError, OnError Power Apps tutorial, Power Apps error handling, Catch unknown errors Power Apps, Power Apps debugging tips, Power Apps 4K tutorial, Power Apps exception handling, Power Apps best practices