9.1 Reusable Components, Named Formulas, and User-Defined Functions

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.1 Reusable Components, Named Formulas, and User-Defined Functions

Key Takeaways Explain This Topic AI

Component libraries create a new numbered version on every publish; consuming apps see an update prompt in Power Apps Studio and keep the old component until a maker accepts the new version and republishes the app

Components inside a component library cannot connect to data sources directly — pass data in through input properties and hand results back through output properties

Named formulas live in App.Formulas, are immutable and always available, and recalculate automatically when their dependencies change, like cells in Excel

User-defined functions extend named formulas with typed parameters and a typed return value; recursion is not supported, and behavior UDFs use a curly-brace body with a Void return type

Choose a component for reusable UI, a named formula for one repeated expression, and a UDF for the same calculation with different inputs

Last updated: July 2026

Building the same badge, header, or calculation over and over is the fastest way to make a canvas app unmaintainable. Power Apps gives you three first-class reuse mechanisms — components , named formulas , and user-defined functions (UDFs) — and the AB-410 exam loves asking which one fits a given scenario.

Canvas app components

A canvas app component is a reusable, self-contained bundle of controls with its own properties, defined once and inserted many times. Components keep their own internal controls and formulas, so they encapsulate complexity instead of copying it.

Components become genuinely useful through custom properties :

Input properties receive values from the host app or screen — the text to display, a color, or a record. Inside the component you bind control properties to the input property name.

Output properties expose calculated values back to the host, such as the date a user picked inside a custom date header or an IsValid flag from a composite input control.

Behavior properties are function-type properties. The host app assigns a behavior formula (one that can call Set , Notify , Navigate , and friends) that runs when the component raises the corresponding event — the classic examples are a component-defined OnReset or a custom event like OnItemSelected .

Scenario: an insurance agency needs an identical policy status badge on six screens. The maker builds one component with an input property Status (Text) and an output property DaysInStatus (Number), then drops it everywhere. When branding changes, one edit updates all six screens.

Component libraries

To share components across apps — not just within one app — you use a component library . In make.powerapps.com , select Component libraries in the left navigation (choose More > Discover all if it is hidden), create a library, and add components in its dedicated editing experience.

Library behaviors to know for the exam:

Versioning. Every publish of a library creates a new numbered version, and publishers should write version notes so consumers know what changed.

Sharing. A library is shared with makers; consumers need permission before its components appear for them.

Import. In a consuming app, you insert library components from the Insert pane ( Get more components ). The app keeps a reference to the library, not a disconnected copy.

Update propagation. When the library publishes a newer version, the consuming app does not silently change. The next time a maker opens the app in Power Apps Studio, an update available prompt lets them review and accept the new version. End users of the already-published app keep the old component until the app maker accepts the update and republishes.

Exam trap: components inside a component library cannot connect to data sources directly (and cannot use offline functions such as SaveData / LoadData ). Design them to receive data through input properties and return results through output properties. A component library also cannot consume components from another library.

Named formulas

A named formula assigns a name to an expression in the App.Formulas property:

UserEmail = User().Email; CurrentEmployee = LookUp( Employees, 'Primary Email' = UserEmail );

Compared with initializing global variables in App.OnStart , named formulas are:

Always available — no timing dependency on OnStart running first; formulas can reference each other in any order (circular references are blocked) and can be computed in parallel.

Always up to date — they recalculate automatically when their dependencies change, exactly like cells in Excel, and only recalculate when needed.

Immutable — the definition in App.Formulas is the single source of truth; no stray Set elsewhere in the app can secretly change them.

Deferred — values are calculated only when needed, which can improve app load time.

Limitations: named formulas cannot use behavior functions or cause side effects (no Set , Collect , or Notify inside), and circular references are not allowed.

User-defined functions

User-defined functions (UDFs) extend named formulas with parameters, and are also defined in App.Formulas:

FullName( First: Text, Last: Text ): Text = Trim( First & " " & Last );

Every parameter and the return value must be typed — Text , Number , Boolean , a data source name, or an aggregate type built with the Type and RecordOf functions. You can then call FullName( "Ada", "Lovelace" ) anywhere in the app.

Current limits to remember:

Recursion is not supported.

Record matching for parameters is strict: the record you pass must be a proper subset of the declared type — extra fields cause an error.

Behavior UDFs are possible: wrap the body in curly braces and use Void as the return type when the function performs actions (for example, adjusting a total with Set ) instead of returning a value.

Related user-defined types are declared with := , for example Book := Type( { Title: Text, Author: Text } ) .

Choosing the right tool: exam scenario table

Scenario Best choice Why

Same visual control layout on many screens or apps Component (in a library) Encapsulates UI with input/output/behavior properties

One expression repeated across many property formulas Named formula Single source of truth, always current, immutable

Same calculation with different inputs UDF Typed parameters plus a return value, callable anywhere

Initialize state or write data when an event fires Variable / behavior formula Named formulas cannot perform side effects

Reusable logic that must also call Notify or Set Behavior UDF Curly-brace body with a Void return type

Exam traps: OnStart -initialized variables are not 'always up to date' — a named formula is. Library components do not auto-update in published apps — a maker must accept the new version and republish. And a named formula cannot call Set — use a behavior UDF or a plain behavior formula instead.