9.2 Managing Variables and Collections

State is where canvas app bugs hide. Power Fx offers several ways to store values — global variables, context variables, collections, and the scoped With function — and the AB-410 exam expects you to know exactly where each one lives and when it is appropriate.

Global variables with Set

A global variable is created with Set( varTotal, 0 ) and is available on every screen of the app. Power Fx declares variables implicitly: the first Set that mentions a name creates it, and its data type is inferred from the value assigned. There is no declaration statement and no type annotation.

Global variables suit app-wide state: the signed-in user's role, a shopping cart record, a debug flag. But convenience invites abuse — the 'Set everywhere' anti-pattern is an app where dozens of formulas write to the same variable from different screens, making the current value impossible to predict. Prefer named formulas in App.Formulas for derived values, and reserve Set for genuine app state that events change.

Context variables with UpdateContext

A context variable is created with UpdateContext( { locShowPopup: true } ) and is scoped to the screen where it is created. Two screens can each have a locShowPopup context variable with completely independent values. Context variables are the right tool for per-screen UI state: whether a dialog is open, which tab is selected, the record currently being edited.

You can also create context variables on the target screen when navigating:

Navigate( DetailScreen, ScreenTransition.None, { locSelectedID: Gallery1.Selected.ID } );

The record passed as the third argument becomes context variables on DetailScreen — the standard pattern for passing data between screens. UpdateContext itself can only set variables on the current screen, and App.OnStart cannot use UpdateContext at all, because no screen exists yet when OnStart runs.

With: scoped evaluation without state

With( { radius: Slider1.Value }, Pi() * radius^2 ) evaluates a formula using one or more scoped named values, then discards them. Nothing is stored; nothing persists. Use With to break a long nested formula into readable steps, to grab a record once and reference its fields many times, or to make App.OnError handlers safe from concurrent re-evaluation. If a value doesn't need to outlive the formula, With beats both Set and UpdateContext.

Collections: in-memory tables

A collection is an in-memory table you can add to, update, and clear:

ClearCollect is the workhorse for caching reference data at startup, typically in App.OnStart or a screen's OnVisible. Keep collections for genuinely tabular, mutable working sets — an offline queue, a shopping cart, a multi-select staging list. If the data is a single derived value, a named formula is simpler; if it is a single record being edited, a global variable or context variable is enough. Reaching for a collection by default adds serialization and memory cost you did not need.

Delegation: the collection snapshot trap

A collection holds a snapshot of data taken at the moment it was filled. Two consequences matter for the exam:

1. It does not refresh itself. If another user edits the Dataverse table, colProducts keeps stale rows until you run ClearCollect again.
2. Delegation stops applying. When you run ClearCollect( colBig, Filter( BigTable, <non-delegable test> ) ), Power Apps pulls only the first rows up to the data row limit — 500 by default, configurable up to 2,000 in the app's settings — and evaluates the non-delegable filter locally against just those rows. A 10,000-row table quietly becomes a 500-row collection, and the app never errors. Watch for the blue delegation warning underline in Power Apps Studio.

Inspecting state: the Variables pane

Power Apps Studio's Variables pane in the left rail lists every global variable, every context variable grouped by screen, and every collection, together with where each is defined and where it is used. It is the first place to look when a variable behaves unexpectedly.

Naming conventions and common traps

Teams conventionally prefix names: var for global variables, loc for context variables, col for collections. Nothing enforces this, but it prevents the classic confusion of treating a screen-scoped value as global.

Exam traps:

• Because variables are implicitly declared, a typo like UpdateContext( { locSowPopup: true } ) creates a new variable — no error appears, and the intended variable never changes.
• A context variable set on Screen A is invisible on Screen B; reading it there returns blank.
• Using Set to cache a value that could be a named formula reintroduces timing bugs — with the non-blocking OnStart behavior, another rule may read the variable before OnStart finishes initializing it.
• Collect appends duplicate rows every time it runs; use ClearCollect when you mean 'refresh the cache'.