Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

feature-power-fx-language.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn

What it does

Power Fx is the low-code formula language behind Power Apps and the wider Power Platform. It's strongly typed, declarative and functional, and it borrows its types, operators and function semantics from Excel wherever Excel has an answer — falling back to SQL where Excel doesn't.

Key facts

  • Formulas bind an expression to a name or a control property, and recalculate automatically when anything they depend on changes. There are no OnChange handlers for this — the dependency graph does it.
  • Strongly typed with type inference. Types are known at compile time, so conflicting usage is a compile-time error. Polymorphic values must be pinned to a static type with IsType and AsType before use.
  • There's no undefined value. Uninitialised variables start blank, and anything that would be undefined elsewhere is either blank or an error. Every data type can be blank.
  • Data operations are asynchronous, and the language handles delegation, projection, relationship traversal and paging without the maker declaring any of it.
  • The decimal separator follows the author's language. In comma-decimal locales the list separator becomes ; and the chaining operator becomes ;; — the same formula reads differently for a French maker and a British one.
  • An incremental compiler keeps the app live while you edit. There's no build or compile step, only publish.
  • Formulas can be stored in YAML source files, which is what makes source control and text editing possible.
  • Language changes are handled with a version stamp on every saved document plus back-compat converters that rewrite formulas on next edit. ShowError being replaced by Notify is the documented example.

When to use / skip

There's no choosing here — if you're building canvas apps or custom pages you're writing Power Fx, and it also drives model-driven command bar buttons. The judgment call is how far to push it. Power Fx is genuinely good at declarative binding and data mashing, and genuinely awkward at long imperative sequences, recursion and anything that wants a real loop with state. When a piece of logic starts fighting the language, that's usually the signal to move it to a Dataverse action, a plug-in or a flow rather than to write a cleverer formula.

Configuration decisions

  • Where the boundary sits between declarative formulas and imperative behaviour formulas, since the second is harder to reason about and harder to test.
  • Whether the team writes formulas in Studio or in YAML under source control, which affects your whole ALM story.
  • How much you rely on automatic delegation and projection versus explicitly shaping data before it reaches the app.
  • Which locale the team authors in, if you have makers across regions and the separators differ.

Gotchas

  • Excel-consistency only goes so far. Len() is a function not a property, the language isn't object-oriented, and people coming from JavaScript trip over that for a week.
  • Blank coerces to zero in arithmetic, so an empty text input divided into something gives you a division-by-zero error rather than a blank result.
  • Locale-sensitive separators mean a formula pasted from a blog post written in a comma-decimal locale won't parse for you, and the error message won't say why.
  • "Always live" cuts both ways — an error in one formula shows immediately in Studio while the rest of the app keeps running, so it's easy to publish with a red squiggle you stopped noticing.

Consultant notes

  • Pitch Power Fx to business stakeholders as Excel formulas over their real data, because that's the honest comparison and it lands. Don't pitch it as a programming language to non-developers.
  • Warn pro-dev teams early that this is a functional, declarative language. Developers who try to write procedural code in it produce the worst apps on the estate.
  • Agree naming and formatting conventions on day one. Power Fx has no compiler-enforced structure, so consistency is entirely a team discipline problem.
  • Watch this one across release waves — Power Fx moves quickly, and features like user-defined functions and types changed what "good" looks like within a single year.

Worth revisiting each release wave, or whenever Power Fx lands in another product surface.

Was this accurate?