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

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:

1. Versioning. Every publish of a library creates a new numbered version, and publishers should write version notes so consumers know what changed.
2. Sharing. A library is shared with makers; consumers need permission before its components appear for them.
3. 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.
4. 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

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.