What it does
A named formula gives a name to an expression in the App.Formulas property, and you use that name anywhere in the app in place of the expression. It behaves like a named cell in Excel: always current, always available, and calculated by the system when it's actually needed.
Key facts
- Defined in App.Formulas, one after another, each ending with a semicolon. The type is inferred from the expression.
- The value is always available. There's no timing dependency and no OnStart that has to run first, so there's no window in which the value is wrong.
- The definition is immutable. Nothing elsewhere in the app can overwrite it, which removes the whole class of "who set this variable" debugging.
- Named formulas can reference each other in any order, as long as there's no circular reference.
a = b;andb = a;in the same app is rejected. - Calculation is deferred. A formula that's only used on screen 2 isn't calculated until screen 2 needs it, and there's no cost to defining a formula you never use.
- They can't call behaviour functions or cause side effects. Set, Notify, Collect and friends are out.
- Named formulas are available in App.StartScreen, where global variables and collections created in OnStart are not.
- Microsoft's own guidance on OnStart now points at named formulas first for caching data and setting up global values.
When to use / skip
Default to a named formula and only reach for a global variable when you genuinely need mutable state. Anything derived — the current user's record, a permission flag, a theme colour, a filtered reference list — is a formula, not a variable. Keep variables for things a user action actually changes, like the currently selected item or a form mode. The migration from a heavy OnStart to App.Formulas is one of the few refactors that reliably improves app load time without changing behaviour.
Configuration decisions
- Which existing OnStart globals become named formulas, and which have to stay variables because something writes to them.
- How the formulas are ordered and grouped in the property, since there's no structure imposed and this file grows fast.
- Naming conventions that distinguish named formulas from variables and collections at a glance, because nothing in the syntax does.
- Whether expensive lookups belong in a named formula or should be collected once, given the formula recalculates when its dependencies change.
Gotchas
- A named formula recalculates whenever anything it depends on changes. Base one on a control property and you get a data call on every keystroke unless you're careful about the dependency.
- Because they can't have side effects, the migration from OnStart is never a straight copy. Anything with a Collect or a Set has to be restructured rather than moved.
- Circular references are rejected, but the error surfaces at the definition, not where you used the name, so a two-step cycle across a big Formulas property takes a while to find.
- App.Formulas is a single text property with no outlining. On a large app it becomes a wall of formulas that nobody wants to touch.
Consultant notes
- Introduce App.Formulas at the start of the build. Converting a mature app's OnStart later is a genuine piece of work and it'll be quoted as a bug fix.
- Sell it on determinism, not speed. "The value can't be wrong and nothing else can change it" is a better argument to a technical lead than a load-time number you can't guarantee.
- Watch this one alongside user-defined functions — they're an extension of the same property and the same mental model, and they're best taught together.
- If the client has an existing estate, an audit of OnStart across apps usually turns up the same five globals reimplemented differently in each. That's a quick, visible win.
Worth revisiting if App.Formulas gains any authoring structure, or if OnStart is deprecated further.