Tag: Power Fx

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published May 17, 2026

The May 2026 Power Platform feature update dropped on May 14 and the list is long. Copilot updates, Dataverse changes, governance bits. But the one item I keep coming back to is Power Fx user defined types going generally available. If you write any non-trivial Power Apps, this is the change that matters. UDTs are GA as of version 3.26044, enabled for new apps by default, and switchable on existing apps through settings.

What Power Fx user defined types GA actually does

UDTs let you define a named, structured type once and use it everywhere in your app. You declare them with the Type function in the App’s OnStart or named formulas. Something like Type({ Id: Text, Name: Text, Status: Text, DueDate: DateTime }) bound to a name, and now every function signature, every variable, every collection can reference that type by name.

Before UDTs, type information in Power Fx was inferred from whatever record you happened to pass first. Pass a record with one less field and Power Fx would silently widen or narrow the schema. Build a component that took a record parameter and good luck enforcing what was inside it. The result was a lot of defensive coding, a lot of IfError, and a lot of runtime surprises.

With UDTs you get a contract. A function expects a specific shape. A component prop declares what it accepts. Collections carry a known schema instead of guessing from the first row. The Type function reference covers the syntax if you want the official version.

Why it matters for app maintainability

Power Apps has had a maintainability problem for years. Not because the platform is bad. Because untyped records meant every medium-sized app slowly turned into a pile of implicit assumptions. You open someone else’s screen six months later and you cannot tell what shape locSelectedItem is supposed to be without running the app and inspecting it live.

UDTs make those assumptions explicit. The variable has a type. The component prop has a type. The function returns a type. When the schema changes, you change it in one place and Power Fx tells you everywhere it breaks. That is the difference between a 2000-line app you are afraid to touch and one you can actually refactor.

There is a real trade-off though. You give up some of the speed of just throwing a record into a variable and moving on. For tiny apps that is overkill. For anything that more than one person touches, or anything that lives longer than a quarter, the upfront type definition pays for itself the first time you onboard a new developer.

The other thing UDTs do, and this is the part I find more interesting, is that they make Power Fx feel like a language you can actually build component libraries in. Reusable components have been technically possible for a while. They have not been pleasant because the prop interface was loose. With named types, a component library starts looking like an SDK instead of a copy-paste exercise. If you are thinking about how governance fits around that kind of library work, Power Platform governance that does not kill adoption is worth a read before you start standardising component patterns across teams.

What I would do with Power Fx user defined types this week

Pick one existing canvas app. Not a critical one. Something internal that you wrote and you are tired of debugging. Enable UDTs through settings, updates, new, user-defined types.

Then find the single record shape that gets passed around the most. The selected item from your main gallery, the form values for your main edit screen, the API response from your most-used connector. Define it as a UDT in App.OnStart with the Type function. Give it a clear name. Refactor the three or four places that record gets read or written to use the named type.

You will hit one or two spots where Power Fx now flags a mismatch that was silently working before. That is the point. Those mismatches were latent bugs. Fix them. Then look at any component you wrote that takes a record input and convert the prop to your new named type.

That is enough for week one. Do not try to type the whole app at once. The way I have seen this go sideways elsewhere is people treating UDTs like a migration project instead of a habit. Start with one type, one screen, one component. Build the muscle.

I have written before about moving business logic out of system prompts and into managed artifacts, and UDTs are the same idea at the Power Fx layer. Put the contract in one place, let everything else reference it, and stop hiding the schema in tribal knowledge. If you are wiring typed records into flows alongside your canvas apps, the Power Automate error handling patterns post covers how to keep that layer equally explicit about what it expects and what it does when things break. More notes on what I am building with this are on my LinkedIn.

This is the kind of change that does not look exciting in a release post and ends up changing how I write Power Fx every day.

Source: What’s new in Power Platform: May 2026 feature update (Microsoft Power Platform Blog).