People ask about “the right way to use variables in Power Apps canvas apps” quite often, so this post summarizes my personal approach.
In my experience, variables are also one of the top reasons apps become hard to maintain—especially during handover—so choosing the smallest possible scope usually pays off.
Power Apps variables: 3 types (3 scopes)
In Power Apps, variables can be grouped into three types (more precisely, three scopes):
- Set / Collections (global, app-wide)
- UpdateContext (screen-level)
- With (formula/block-level)
Because these options differ mainly in scope (where values can be accessed and modified), the key is to pick the smallest scope that still satisfies the requirement.
Set / Collections
First are global variables created with Set() and collections created with ClearCollect() (and related functions).
Scope: app-wide (global). You can reference and change them from anywhere in the app.
That “available anywhere” property is convenient, but it also increases the risk of regressions during refactoring and makes handover harder, because anything can modify the same value from multiple places.
Personally, I mostly used Set() for constants in the past, but since App.Formulas (Named Formulas) became generally available, I use Set() much less for that purpose.
Still, there are legitimate cases where you truly need app-wide state (for example, a shopping cart, or whether a side menu is open/closed), so my rule is: use global variables/collections only when app-wide state is required.
Global variables and custom components
Global variables created with Set() can also be accessed from custom components when Access app scope is enabled.
UpdateContext
Next is the context variable created with UpdateContext().
Scope: screen-level. The variable is scoped to the screen where it’s defined.
Because the scope is narrower than global variables, many best-practice guides recommend using UpdateContext() where possible—and I also tend to do that (for example, UI state like modal/popup visibility).
Collections vs. table-type context variables
If you want to keep multiple items retrieved from SharePoint (or another data source), it’s common to reach for a collection.
However, if you don’t need to mutate the list (e.g., you won’t Collect() new rows or Remove() existing ones), a table-type context variable is often enough.
Using a collection without a strong reason effectively widens scope (accessible across the app), so I personally prefer a table-type context variable unless I specifically need collection behaviors.
Context variables passed via Navigate
One caution: Navigate() can pass values to the destination screen, which can make it easy to accidentally treat “incoming parameters” like local state and overwrite them in many places—sometimes causing subtle bugs when users move between screens.
Naming tip: For readability, it can help to name local context variables with a prefix like loc, and values passed between screens with a prefix like param/prm/arg.
With
Finally, there is With(). Variables defined in the first argument of With() are scoped only within the With block, making this the smallest scope among the three.
This function is surprisingly underused, but it’s one of my favorites because it holds values in a “just-right” scope and helps avoid leaking state across screens or the whole app.
Example use case: if you want to check the return value of Patch(), refresh the form on success, and show an error message if it fails (e.g., returns Blank()), you can often implement it cleanly with With() without relying on UpdateContext().
Using
Withcan make formulas self-contained and easier to understand, and it works well in a declarative context—so it is often preferred over context variables or global variables.
Summary (my rule of thumb)
My personal guideline is:
Try With first. If that doesn’t work, use UpdateContext. If you still can’t solve it with screen-level scope, then use Set / collections as the last resort.
Variables are often one of the trickiest parts of maintaining and handing over Power Apps canvas apps. Even though editor features like search/replace have improved, choosing the right scope and using consistent naming still makes a big difference for the next maintainer.
コメント