Power Apps: Log Errors with UDFs

Key insights

• User Defined Function (UDF): Use a UDF to capture and record unhandled Power Apps errors centrally.
  It runs when errors occur so you don’t lose transient messages and can analyze issues later.
• SharePoint list: Create a simple "Error Log" list with columns like ControlName, User, ApplicationName, ApplicationID, SessionString, ErrorMessage, and Timestamp.
  Store each error as one record to enable filtering and reporting.
• App.OnStart: Set global values at startup (app name, app ID, session ID, current user) so each log entry carries context.
  These globals make it easy to correlate errors across sessions and users.
• LogError and Patch: Build a reusable LogError function that calls Patch to write error details to the list.
  Include fields such as FirstError.Message, FirstError.Source, FirstError.Observed, user info, and timestamp for faster root-cause analysis.
• IfError and App.OnError: Use IfError for specific operations and App.OnError to catch all unhandled errors app-wide.
  Call your LogError UDF from both places to ensure consistent, centralized logging.
• Error suppression and Email notifications: Suppress repetitive messages in the UI to avoid user fatigue and throttle logging when needed.
  Send targeted email alerts (for example via the Office 365 Outlook connector) for high-priority errors so developers receive timely notifications.

Overview of the Video and Its Purpose

In a recent YouTube video, Shane Young [MVP] explains a practical method to capture and log errors in Power Apps so developers stop losing traceability when unexpected failures occur. He demonstrates using a User Defined Function to write error details into a persistent store such as a SharePoint list, and he walks through both targeted and global ways to trigger that logging. Consequently, the approach aims to make debugging more reliable by preserving context like the error message, source control, user, session ID, and timestamp.

Moreover, the video covers complementary techniques for different scenarios, including logging from IfError blocks and wiring a central handler via App.OnError. Shane also addresses how to avoid overwhelming developers with noise by suppressing repetitive errors and how to set up Outlook email notifications for critical failures. Therefore, the material combines hands-on steps with practical guidance to move teams from ad-hoc notifications to a centralized error-management pattern.

How the Logging Method Works

At its core, the method uses a reusable logging function—often named LogError—that formats error details and uses a Patch operation to write a new record into an error log list. Shane explains that the function should capture fields such as control name, current user, app name, app ID, session string, the full error message, and a timestamp so each log entry is actionable. Then, developers call that function from local error handling blocks like IfError or register it once to the app-wide App.OnError property to intercept unhandled errors.

In addition, the video shows how to predefine global variables on app start for contextual values such as application name and session ID, which keeps the logging payload concise and consistent. This setup allows the log to include consistent identifiers for correlation across multiple errors and user sessions. Consequently, when an error arrives in the list, teams can quickly filter and investigate based on time, user, or control context.

Implementation Highlights Demonstrated

Shane walks viewers through creating the error log list schema and then defines the logging expression that maps error properties to list columns. For example, he uses values like FirstError.Message and FirstError.Source to collect diagnostic details, while maintaining a simple record structure to keep queries fast. He also demonstrates wiring the same function into both local and global handlers so make-or-break issues do not slip through unnoticed.

Furthermore, the video discusses adding basic resiliency in the logging call to prevent cascading failures, such as conditional checks before Patch and graceful handling when the logging store is unavailable. Shane suggests techniques to reduce write contention and to avoid infinite loops when a logging attempt itself throws an error. As a result, developers can implement logging that is robust enough for production without adding instability.

Tradeoffs and Challenges to Consider

While the approach is practical, it involves tradeoffs that teams should weigh carefully. Using a SharePoint list or similar low-cost store keeps costs down and simplifies setup, but it may reach throttling or storage limits in high-volume apps, which undermines scalability. Conversely, premium tools like Application Insights offer richer telemetry and query capabilities but require additional licensing and configuration, so teams must balance capability against cost and permissions.

Another challenge lies in managing noise and privacy. If logging captures too much information, the log can quickly overwhelm the team and expose sensitive data, so it is important to filter and sanitize error text before writing it. Additionally, logging every minor validation issue can create operational burden, so Shane recommends suppressing duplicate errors and adding thresholds or sampling to reduce volume. Accordingly, finding the right balance between completeness and signal quality is key to long-term usefulness.

Best Practices and Practical Recommendations

To make the system effective, Shane emphasizes modularity and reuse: define the User Defined Function once, store global context at app start, and call the function consistently from both local and global handlers. Moreover, instrument the log with fields that support triage, such as severity, session ID, and the origin control, so incidents are actionable without extra back-and-forth. Consequently, teams gain faster mean time to repair and clearer audit trails for recurring issues.

Finally, Shane suggests pairing logging with selective notifications for critical failures, for example sending Outlook alerts only when severity exceeds a threshold. He also advises monitoring the logging store health and implementing retry or fallback logic to avoid blind spots. In summary, his video provides a pragmatic path to capture errors reliably while highlighting tradeoffs, and it equips makers with patterns they can adapt to their scale and governance needs.

Keywords

Power Apps error logging, Power Apps error handling, Log errors with user defined functions Power Apps, Power Apps custom logging, Power Apps troubleshooting tips, Power Apps telemetry and monitoring, Power Apps user defined function error logging, Prevent losing Power Apps errors