Power Fx named formulas

Named formulas are a relatively recent addition to canvas apps that, once understood, change how an experienced maker organises code. They're named expressions evaluated lazily when referenced, with no explicit assignment and no implicit recomputation cost — a properly functional layer on top of Power Fx that complements (and often replaces) variables.

The historical pattern: variables. Canvas apps have long had variables — Set(varCurrentUser, User()), UpdateContext({selected: thisItem}). Variables are mutable, assigned imperatively, persist until reassigned. They're familiar to developers from imperative languages but they create classic problems: out-of-date values, race conditions on async work, scattered assignments.

Named formulas in App.Formulas. In the canvas app App object's Formulas property:

CurrentUser = User();
DefaultSiteId = First(Sites).Id;
TodayLabel = "Today is " & Text(Today(), "long");
GrossMargin = SalesAmount - CostAmount;

Each line names a formula. Anywhere the name is referenced, the formula re-evaluates. There's no Set, no Update. The compiler can detect dependencies and recompute lazily.

Properties.

• Declarative — you say what it is, not when to compute it.
• Pure — no side effects allowed in the formula.
• Lazy — only evaluated when referenced.
• Cached intelligently — re-evaluated when dependencies change, not on every reference.
• Constant by reference — the name always means the same expression, never "the value at a moment in time."

Compared to variables.

| Aspect | Variable | Named Formula | |---|---|---| | Assignment | Set(name, value) | name = expr; in App.Formulas | | Mutability | Mutable | Immutable definition | | Update | Manual via Set | Auto-recompute on dependency change | | Side effects | Allowed | Not allowed | | Scope | App-wide or screen-local | App-wide | | Asynchronous | Yes, can store Patch results | No, must be synchronous |

When to use named formulas.

• Derived values — anything computed from other state.
• Configuration constants — labels, defaults.
• App-wide reference data — current user, current language, today's date.
• Pure transformations — formatted labels, filtered collections (where filter inputs are stable).

When to keep using variables.

• Async results — outputs from Patch, custom connector calls.
• Mutable UI state — selected tab, current step in a wizard.
• Counters and toggles — anything explicitly time-varying.

Example: replacing OnStart variables. A common pattern is loading reference data in App.OnStart:

Set(varCurrentUser, User());
Set(varDefaultSite, First(Sites));
Set(varTodayLabel, "Today is " & Text(Today(), "long"));

Equivalent with named formulas in App.Formulas:

CurrentUser = User();
DefaultSite = First(Sites);
TodayLabel = "Today is " & Text(Today(), "long");

The named formula version:

• Doesn't block app start (lazy).
• Recomputes automatically when underlying data changes.
• Lives in one place; no need to remember Set is called somewhere.

For typical reference data loads, this is a meaningful UX improvement — app starts faster.

Dependency tracking. Power Fx tracks dependencies. If GrossMargin = SalesAmount - CostAmount and SalesAmount is itself a named formula or a data source field that changes, GrossMargin re-evaluates automatically. The maker doesn't trigger updates manually.

Performance. Lazy evaluation means formulas referenced but never used cost nothing. Formulas referenced once compute once. Formulas referenced repeatedly within a render cycle benefit from caching. Heavy formulas referenced in a galaxy of bound controls can still be expensive — design accordingly.

Limitations.

• No side effects — Patch, Notify, Navigate are not allowed.
• Synchronous only — connector calls returning async results not allowed.
• No If/With with control mutation — pure expressions only.
• App-level scope — named formulas live on App, not per screen.

Component formulas. Power Fx custom components can have their own named formulas, scoped to the component. Useful for component-internal derived values without polluting app scope.

Best practices.

• Use named formulas as defaults for any derived value. Reach for variables only when mutability is genuinely required.
• Name carefully — these are app-wide; use Pascal or clear prefixes.
• Refactor large App.OnStart — most Set calls can become named formulas, dramatically simplifying start logic.
• Document the dependency graph when it gets complex — a comment block at the top of App.Formulas listing key formulas helps future maintainers.

Common pitfalls.

• Mixing imperative thinking — trying to "trigger" a formula recompute. Power Fx handles this; if it's not recomputing, it's because dependencies haven't changed.
• Storing async results — won't work; needs variable.
• Over-reliance on App scope — sometimes a per-screen variable is genuinely the right scope.

Operational guidance. Named formulas are the modern default for derived state in canvas apps. They reduce code, improve correctness, and produce apps that are easier for the next maker to understand. The "imperative variable everywhere" style is still common but increasingly outdated.