Named formulas are best for values that can be calculated from other state and should stay current automatically. Put them in App.Formulas. Keep Set() for mutable global state that an action must change. Moving the right calculations out of App.OnStart can also remove startup ordering dependencies.
They are useful, but they are not a blanket performance switch.
A small example
Select App in the tree, choose its Formulas property and define formulas separated by semicolons:
CurrentUserEmail = Lower(User().Email);
OpenRequests = Filter(Requests, Status.Value = "Open");
OpenRequestCount = CountRows(OpenRequests);
OpenRequestCount depends on OpenRequests. Power Fx manages that dependency and recalculates the value when required. The order of named formula declarations does not create an execution sequence, although circular references are not allowed.
Before using the example against a real source, check whether the Filter and CountRows operations delegate for that connector. A named formula does not remove delegation limits.
Named formula or global variable?
Use a named formula when the value is a rule:
DisplayName = Coalesce(User().FullName, User().Email);
TaxRate = 0.2;
Use Set() when the value represents state changed by a behaviour formula:
Set(varSelectedRequest, ThisItem)
The important difference is ownership. DisplayName describes how to calculate a value. varSelectedRequest records what a user did. Trying to use Set() for every derived value creates manual update paths. Trying to use named formulas for mutable state fights the formula model.
Why this can improve startup behaviour
App.OnStart is a behaviour property. Its statements execute when the app starts, and long chains can create ordering and navigation problems. Named formulas are available when referenced and stay current from their dependencies.
Microsoft recommends using App.Formulas instead of App.OnStart for suitable calculated values. Power Fx can schedule independent formulas and avoid evaluating work that is not needed immediately.
This does not mean every data call belongs in App.Formulas. A formula that reads a remote source can still be slow, non-delegable or repeatedly expensive. Measure the actual app with Monitor and keep the data shape small.
Do not create a hidden StartScreen race
App.StartScreen must not depend indirectly on a global variable that App.OnStart sets. Microsoft warns that referencing a named formula from StartScreen when that named formula depends on an OnStart global variable can create a race condition.
Keep navigation inputs declarative. If the first screen depends on a URL parameter, make the named formula depend directly on Param() rather than on a variable initialised later.
A safe migration from OnStart
- List every value set in
App.OnStart. - Mark values changed later by user actions. Keep those as variables.
- Mark values wholly derived from controls, parameters or data. These are named-formula candidates.
- Move one candidate at a time into
App.Formulas. - Check formulas for delegation and repeated connector calls.
- Run the app from a cold start and test deep links and role-based start screens.
- Use Monitor to compare the operation sequence. Do not claim a performance gain from the change alone.
Failure and recovery
If a migrated formula returns blank, inspect its dependencies rather than trying to force an execution order. If it calls a connector, test denied access and connector failure. Keep the previous saved app version until the updated version passes an end-user test, then publish deliberately.
For help separating derived values from app state in a real canvas app, join the Power Apps Builders Space.