Screens and Navigation

Analogy categoryAnalogies

A canvas app is composed of one or more Screen objects, each a top-level container that holds its own tree of controls and has its own OnVisible property, which fires every time that screen becomes active — a natural place to reset variables, refresh a data source, or set a filter default. Moving between screens is handled by the Navigate function, which takes a target screen, an optional visual ScreenTransition (such as Cover, UnCover, or Fade), and an optional third argument, an update record, that sets Context variables on the destination screen at the moment of transition — this is the standard way to pass data like 'which record was selected' from one screen to another.

🏏

Cricket analogy: OnVisible firing every time a screen becomes active is like a broadcast producer resetting the graphics overlay every time coverage switches back to live play after an ad break, ensuring the score shown is always current.

App-Level State and Context Variables

Beyond per-screen context variables set via Navigate, Power Apps supports global variables set with Set(varName, value), which persist across the entire app session and are visible from any screen, and collections created with Collect() or ClearCollect(), which are in-memory, table-shaped data structures useful for caching a filtered dataset, building a shopping-cart-style temporary list, or storing offline data. The App object's OnStart property runs once when the app launches (before the first screen is visible) and is the conventional place to initialize global variables and pre-load small reference collections, though Microsoft recommends against using OnStart for anything that must complete before the first screen renders, since OnStart execution is asynchronous relative to screen loading.

🏏

Cricket analogy: A global variable tracking the current match format across every screen is like a scoreboard operator's master setting for 'T20 rules' that stays consistent no matter which graphic, meaning screen, is currently displayed.

Larger apps typically layer navigation on top of raw Navigate() calls: a persistent side or top navigation bar (a component or a set of icons on every screen) that jumps directly to key sections, a Back function tied to a hardware or on-screen back button that returns to the previous screen without hardcoding a target, and, for tab-like experiences within a single screen, a container with visibility toggled by a variable rather than separate screens entirely — useful when switching 'tabs' should feel instant with no navigation transition at all. Choosing between separate screens and an in-screen tab pattern is mostly a performance and complexity trade-off: more screens means more OnVisible logic to maintain but a cleaner Tree view, while in-screen tabs keep everything in one control tree but can get visually crowded as an app grows.

🏏

Cricket analogy: Back() returning to the previous screen without hardcoding a target is like an umpire's review system returning play to exactly where it left off, rather than resuming from a fixed default point.

power-fx

// App OnStart: initialize global state once at launch
Set(gCurrentUser, User());
ClearCollect(colStatusOptions, ["Not Started", "In Progress", "Done"]);

// Persistent nav bar icon OnSelect (present on every screen)
Navigate(TasksScreen, ScreenTransition.None);

// Hardware/on-screen Back button
Back(ScreenTransition.UnCover);

// In-screen tab pattern: toggling a container's visibility
// Container 'Container_Tab1'.Visible property:
gSelectedTab = 1
// Tab button OnSelect property:
Set(gSelectedTab, 1)

Use Back() instead of Navigate(PreviousScreen, ...) whenever a control should simply return the user to wherever they came from — it avoids hardcoding a specific prior screen and correctly handles multi-step navigation paths.

Each Screen has an OnVisible property that fires every time it becomes active, useful for resetting state.
Navigate() moves between screens with an optional ScreenTransition and an optional context record.
Global variables (Set) persist app-wide; collections (Collect/ClearCollect) hold in-memory table data.
App.OnStart runs once at launch, before the first screen renders, for initializing app-wide state.
Back() returns to the previous screen dynamically without hardcoding a target screen.
In-screen tab patterns toggle container visibility with a variable instead of using separate screens.
Choosing screens vs. in-screen tabs trades Tree view cleanliness against instant tab-switching performance.