Power Apps user-defined functions: syntax, limits and when to use

Power Apps user-defined functions are named formulas with parameters. You write one once in the app's Formulas property, as Name(Param: Type): ReturnType = formula;, and call it from any control the way you call If or Filter. Microsoft announced them as generally available in September 2025; the user-defined types that let them take and return records and tables followed in May 2026.

The syntax

User-defined functions live in the same place as named formulas. In Power Apps Studio, select App at the top of the Tree view, then pick Formulas in the property list to the left of the formula bar. Each definition ends with a semicolon:

// App.Formulas
VatInclusive( Net: Number, Rate: Number ): Number = Round( Net * (1 + Rate), 2 );

Initials( FullName: Text ): Text = Upper( Concat( Split( FullName, " " ), Left( Value, 1 ) ) );

Then call them anywhere, for example in a label's Text:

Text( VatInclusive( ThisItem.NetPrice, 0.2 ), "#,##0.00" ) & " incl. VAT"

The parts of a definition:

Every parameter and the return value must have a type. That's the main thing that separates a function from a named formula, whose type Power Apps works out for you.

Records and tables need a type first

To pass in or return a record or a table, define a user-defined type in Formulas with := and the Type function. RecordOf pulls the record type out of a table type.

// App.Formulas
OrderLine := Type( { Net: Number, Rate: Number } );
OrderLines := Type( [ OrderLine ] );

LineTotal( Line: OrderLine ): Number = Round( Line.Net * (1 + Line.Rate), 2 );

// LineTotal( { Net: 100, Rate: 0.2 } ) returns 120
// LineTotal( { Net: 100, Rate: 0.2, Customer: "A" } ) is an error: Customer isn't in OrderLine

The second call fails on purpose. Records passed to a function are matched more strictly than elsewhere in Power Fx: the record can't carry fields that the type doesn't define. Build the record you pass, with only the fields the type expects.

The Type function doesn't support every data type. Learn lists Currency, Image, Media and Record reference as unsupported, and Void, which only ever appears as a return type.

Behaviour functions

Named formulas, and functions written as above, can't have side effects: no Set, Collect, Patch or Notify. When a function genuinely has to change something, wrap its body in curly braces, separate the steps with semicolons, and use Void as the return type if it gives nothing back:

// App.Formulas
LogVisit( ScreenName: Text ): Void = {
    Collect( VisitLog, { Screen: ScreenName, At: Now() } );
    Notify( $"Opened {ScreenName}", NotificationType.Information )
};

Call it from a behaviour property, such as a screen's OnVisible: LogVisit( "Orders" ).

Microsoft's advice is to avoid changing state where you can, and let formulas recalculate on their own. Keep behaviour functions for real actions, such as saving, logging or notifying.

Turning them on, and their status

They first appeared as an experimental feature in Power Apps Studio 3.24013, rolled out worldwide in February 2024. The separate preview switch was removed in version 2508.3. Microsoft folded them into the New analysis engine switch because they depend on it. Features under New are generally available and fully supported, and are normally on for new apps. In an older app, check that tab and turn the switch on yourself.

Limits to know

• No recursion. A function can't call itself, yet.
• Strict record matching. A record argument with an extra field is an error (see records and tables).
• Types are mandatory. Every parameter and the result need one, and some data types can't be described with Type.
• No side effects without braces. A plain function doesn't support Set, Notify and other behaviour functions; use the behaviour form.
• Copilot doesn't recognise them. Learn lists user-defined functions as a limit of the formula bar's Copilot, both when it explains a formula and when it writes one from a comment. Copilot can't generate named formulas or functions for you either.
• One app at a time. Learn documents user-defined functions only in an app's Formulas property, and describes no way to share them between apps.

Function, named formula or component?

A component can carry logic as well as controls. With Enhanced component properties turned on (Settings > Updates > New), a component can expose an output Function property that the app calls like a function, and an Action property that can change state. Function properties can't read variables or the component's own controls, so everything they need comes in as arguments.

Microsoft's pages don't agree on that feature's status: the component overview still calls it experimental, the component properties page lists it on the New tab and on by default for new apps, and the May 2026 announcement says it's generally available.

For how named formulas, functions and a component library fit together in one app, read named formulas and components. For choosing between a named formula, a variable and a collection, see Power Apps variables.

User-defined functions also come up in interviews; question 11 of our Power Apps interview questions covers what to say.

Sources

• App object in Power Apps: Formulas property and user-defined functions — Microsoft Learn
• RecordOf and Type functions — Microsoft Learn
• Data types — Microsoft Learn
• Understand new, preview, experimental, and retired features in canvas apps — Microsoft Learn
• Rename controls in canvas apps with Copilot (the New analysis engine setting) — Microsoft Learn
• Use Copilot to create and edit Power Fx formulas — Microsoft Learn
• FAQ about using Copilot with Power Fx — Microsoft Learn
• Canvas component properties — Microsoft Learn
• Canvas component overview — Microsoft Learn
• Released version 3.24013 (experimental user-defined functions) — Microsoft Learn
• Power Apps user-defined functions are generally available (2 September 2025) — Microsoft Power Platform blog
• Power Fx: user-defined types generally available (13 May 2026) — Microsoft Power Platform blog