App.OnStart runs behaviour formulas when a canvas app starts. Use it for startup actions that genuinely need side effects, such as setting a session variable or loading a small required collection. Do not turn it into a long, hidden boot script that blocks the first useful screen.
Microsoft now recommends declarative alternatives for much of the work traditionally placed in OnStart: App.Formulas for named formulas and App.StartScreen for choosing the opening screen. The App object reference explains an important boundary: StartScreen cannot depend on global variables and collections created in OnStart.
Good candidates for OnStart
Reasonable startup actions include:
- setting a session-only variable used by several screens
- loading a small reference collection that the app truly needs immediately
- reading non-sensitive cached device data
- initialising an error or telemetry context
Example:
Set(varSessionStarted, Now());
Set(varStartupError, Blank())
Keep user security in the data source. A variable such as varIsAdmin can control the interface, but it must not be the only thing preventing an unauthorised user from reading or changing data.
Move calculated values to App.Formulas
Named formulas recalculate automatically when their dependencies change. They do not need startup ordering and can be available before OnStart completes.
For example, an app might define:
CurrentUserEmail = Lower(User().Email);
TodayLocal = Today();
OpenRequests = Filter(Requests, Status.Value = "Open")
Check delegation on data-backed named formulas. A named formula does not make a nondelegable Filter complete. Microsoft's delegation guidance still applies.
Use StartScreen for initial navigation
Use App.StartScreen to return a screen based on information available without waiting for OnStart:
If(Param("view") = "new", scrNewRequest, scrHome)
Avoid Navigate in OnStart for ordinary opening-screen logic. It serialises startup work and makes the initial route harder to reason about. If screen choice requires connector data loaded by OnStart, show a neutral loading or access-check screen and navigate only after the result is known.
Run independent calls with care
Concurrent can evaluate independent formulas at the same time:
Concurrent(
ClearCollect(colLocations, Locations),
ClearCollect(colCategories, Categories)
)
Do not place formulas in the same Concurrent call when one depends on the other's result. Microsoft notes that dependency order is not guaranteed. See the Concurrent function reference.
Also ask whether both collections must block startup. Data needed only on a later screen can often load in that screen's OnVisible or through a user action.
Handle connector failures
An unhandled startup failure can leave the app blank or partly initialised. Capture the failure and give the user a recovery action:
IfError(
ClearCollect(colLocations, Locations),
Set(varStartupError, "Locations could not be loaded")
)
Do not put raw connector or personal data into the message. Log enough context for support, then provide a Retry button that reruns the specific failed load.
Avoid these OnStart traps
- loading an entire large list into a collection to avoid delegation
- calling the same connector several times for values that can share one response
- assuming the signed-in user has the maker's permissions
- storing secrets in variables
- creating or deleting production records during startup
- relying on an undocumented execution order
Microsoft's canvas app code optimisation guidance recommends reducing dependencies and moving suitable values to named formulas.
Prove the refactor
Use App checker and Monitor, then test a cold start with each important user role. Include connector failure, empty data, a deep link and a slow or interrupted connection. Compare observable behaviour, not an invented universal load-time improvement.
A successful maker run proves only that the selected app version worked with that identity and data state.
For more practical Power Fx patterns that stay understandable after handover, join the Power Apps Builders Space.