9.3 Implementing Error Handling in Canvas Apps

Microsoft Certified: Intelligent Applications Builder Associate AB-410

Track your progress as you read

Finished sections get a check mark.

1 Introduction

1.1 About the AB-410 Exam 1.2 How to Use This Study Guide

2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools

2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options

3 Chapter 3: Environments and ALM Strategy

3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy

4 Chapter 4: Dataverse Tables and Columns

4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns

5 Chapter 5: Relationships, AI Data Features, and Data Security

5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security

6 Chapter 6: Model-Driven App Forms and Views

6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language

7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps

7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards

8 Chapter 8: Creating and Designing Canvas Apps

8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps

9 Chapter 9: Canvas App Components, Variables, and Error Handling

9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps

10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps

10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App

11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals

11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows

12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting

12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows

13 Chapter 13: Building Prompts in AI Hub

13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt

14 Chapter 14: Prompt Settings, Models, and Consuming AI

14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows

15 Chapter 15: Business Rules and Business Process Flows

15.1 Configuring Business Rules 15.2 Configuring Business Process Flows

16 Chapter 16: Calculated Columns and Business Logic Strategy

16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic

9.3 Implementing Error Handling in Canvas Apps

Key Takeaways Explain This Topic AI

IfError replaces an error with a fallback value (and supports chained fallbacks evaluated left to right); IsError only reports whether an error occurred and cannot substitute a value

Errors( DataSource ) returns a table of server-side write errors after Patch, SubmitForm, or Remove — test it with IsEmpty immediately after the operation

App.OnError runs with FirstError and AllErrors in scope but cannot replace an error's value; it controls reporting only, and you rethrow with Error( FirstError ) to keep the default banner

Notify shows a banner with NotificationType Error, Information, Success, or Warning and displays for 10 seconds by default

Validate( DataSource, Column, Value ) surfaces validation problems before a write, and flow failures should be returned through the 'Respond to a PowerApp or flow' action and caught with IfError

Last updated: July 2026

Unhandled errors in a canvas app surface as red banners and blank controls — tolerable during development, unacceptable in production. The AB-410 exam expects you to handle errors deliberately at three levels: inside formulas, against data sources, and globally on the App object.

How Power Fx treats errors

An error is a value that flows through a formula. Division by zero, a failed connector call, a blank record where a value was expected — each produces an error value, and evaluation generally continues rather than halting. If nothing handles the error, the affected property shows blank and the app raises a red error banner. Your job as a maker is to decide which errors become fallback values, which become notifications, and which should be logged.

IfError: replace the error with a value

IfError( 1/Slider1.Value, 0 ) evaluates the first formula; if it returns an error, IfError returns the fallback instead. IfError accepts chains — IfError( Formula1, Fallback1, Formula2, Fallback2, DefaultFallback ) — evaluating each pair in order and returning the first non-error result, so you can try a primary data source, then a cache, then a constant.

Two scope records are available inside the fallback formulas: FirstError (a record with fields such as Message , Source , Observed , and Kind ) and AllErrors (a table of every error found). IfError works in behavior formulas too: IfError( Patch( Orders, ... ), Notify( 'Save failed', NotificationType.Error ) ) runs the notification only when the patch errors.

IsError: test without replacing

IsError( Formula ) returns true if the formula produced an error and false otherwise. The crucial semantic difference:

IfError replaces a value — use it when you need a result regardless of failure.

IsError reports a fact — use it to branch logic (for example, toggling a context variable that shows a retry panel) when you do not need to substitute a value.

A classic exam trap is expecting IsError to supply a fallback value. It cannot — it only returns a Boolean.

Errors(): data source errors after writes

When SubmitForm , Patch , or Remove fails server-side — a required column is blank, a Dataverse business rule rejects the change, or two users edited the same record (an ErrorKind.Conflict ) — call Errors( DataSource [, Record ] ) . It returns a table of errors with columns such as Column , Message , and Error (an ErrorKind value like ErrorKind.Validation ). Test it with IsEmpty immediately after the write:

If( IsEmpty( Errors( 'Order List' ) ), Notify( 'Saved', NotificationType.Success ), Notify( First( Errors( 'Order List' ) ).Message, NotificationType.Error ) );

For a conflict, the fix is to Refresh the data source and reapply the user's change against the current record.

Notify: user feedback

Notify( 'Your order was saved.', NotificationType.Success ) shows a banner. The types are Error (red), Information (blue), Success (green), and Warning (yellow). The banner displays for 10 seconds by default ; pass a third argument in milliseconds to change it. Notify is the standard way to surface a handled error instead of letting the raw red banner appear.

App.OnError: the global safety net

The App.OnError property runs when any unhandled error occurs anywhere in the app, and it is evaluated with the same FirstError and AllErrors scope variables as IfError. Critical semantics:

OnError cannot replace the error's value — by the time it runs, the error has already flowed through the calculation. It controls reporting only. To change the value, wrap the original formula in IfError.

If OnError is empty, the default red banner shows FirstError.Message .

To log an error but keep the default banner, Trace first and then rethrow with Error( FirstError ) .

OnError formulas evaluate concurrently and can overlap with other errors, so a global variable written at the top of OnError may change before you read it later in the same formula. Use With to capture FirstError into a stable scoped value.

Preventing errors: Validate with Patch

Validate( DataSource, Column, Value ) — or the whole-record form — returns any validation errors before you write: required columns left blank, wrong types. Combine it with Patch for a belt-and-braces save: validate first, show messages with Notify, and only Patch when validation returns nothing.

Flow failures

When an app triggers a Power Automate flow with MyFlow.Run( ... ) , design the flow to finish with the 'Respond to a PowerApp or flow' action, returning a status code and message body the app can inspect. Wrap the call itself in IfError to catch connector-level failures — timeouts, throttling — that never reach your response action, and Notify the user with the returned status.

Test error paths deliberately

Do not wait for production to discover your error handling. Force a divide-by-zero by binding a label to 1/Slider1.Value and sliding to 0, call the Error function with a custom kind and message to simulate a failure, and watch everything in Monitor , including Trace output from OnError. Test each path — IfError fallback, Errors() message, OnError logging — exactly as you test the happy path.

Error-handling cheat table

Formula Returns Use it to...

• IfError( f, fallback ) f's value, or the fallback on error Substitute a safe value
• IsError( f ) Boolean Branch logic on failure
• Errors( DataSource ) Table of errors Inspect server-side write failures
• Notify( msg, type [, timeout] ) (behavior) Tell the user what happened
• App.OnError (behavior) Globally intercept and log unhandled errors
• Validate( ds, col, value ) Error or blank Catch bad data before a Patch
• Error( FirstError ) Raises an error Rethrow inside OnError or simulate failures
• Trace( msg ) (behavior) Write diagnostics to Monitor

Exam traps: IfError chains evaluate left to right and stop at the first success. OnError cannot substitute values — only IfError can. Errors() reports data source errors, not math errors. And a blank result with no banner usually means an IfError somewhere upstream swallowed the error.