Named Formulas in Power Apps: Streamlining Logic and Configuration

If you’ve ever copied the same Filter expression onto five screens or written a global variable just to hold a user’s email, named formulas can streamline your work. The App Formulas property lets you define custom functions that recalculate every time they are referenced, always reflecting the latest data without storing state. They behave like read-only cached values – each time a formula is used, its result is computed, and that result is shared across all consumers until the data changes.

In this article we’ll build a (fictional) field equipment management app as a running example. Our app needs to display only operational assets, show the current user’s profile picture, hide an admin screen for non‑supervisors, handle launch parameters from a deep link, read environment variables, and keep a consistent colour palette. Let’s see how named formulas handle each requirement.

Named Formulas vs. Variables – a Quick Distinction

Variables (Set, UpdateContext) hold a value you explicitly change. Named formulas hold an expression that re‑evaluates automatically when its dependencies change. They are perfect for any value that is derived from other sources (filtered lists, user info, URL parameters) and that should always be up‑to‑date without extra code.

Good to know: You cannot use Set, Collect, or Navigate inside a named formula. They are pure, side‑effect‑free calculations.

1. Pre‑Filtering Core Data Used Everywhere

Most apps show the same subset of data on multiple screens. In our scenario, we have a SharePoint list called FieldAssets with these columns:

Every screen that lists equipment should only show rows where Status = "Operational". Instead of repeating Filter on each gallery or control, create one named formula:

fxActiveAssets = Filter(
  FieldAssets,
  Status.Value = "Operational"
)

Now set the Items property of any gallery to fxActiveAssets. If the list changes or a user updates a status, the gallery automatically refreshes because the formula recalculates.

2. Caching the Current User’s Profile and Photo

The User() function returns only the display name, email, and image URL. If you need the department, job title, or a high‑resolution photo, call the Office 365 Users connector. Multiple calls to that connector can slow down your app, so store the results in a named formula.

First, add the Office 365 Users connector to your app. Then in the Formulas property write:

fxCurrentUser = Office365Users.MyProfile();
fxCurrentUserPhoto = If(
  Office365Users.UserPhotoMetadata(fxCurrentUser.UserPrincipalName).HasPhoto,
  Office365Users.UserPhotoV2(fxCurrentUser.UserPrincipalName)
)

Now you can reference fxCurrentUser.JobTitle or display fxCurrentUserPhoto in an Image control. The connector results are cached by the named formula – they are retrieved once and reused until the app is closed or the cache expires.

3. Checking Security Roles for Conditional Visibility

If your app uses Dataverse, you often need to know whether the current user holds a specific security role (e.g., “Asset Supervisor”) to show or hide an admin screen. Instead of writing a complex lookup on every screen, create two named formulas.

Add the Users and Security Roles tables from Dataverse to your app, then write:

fxUserRoles = LookUp(
  Users,
  'Primary Email' = User().Email
).'Security Roles (systemuserroles_association)'.Name;

fxIsSupervisor = "Asset Supervisor" in fxUserRoles

Use fxIsSupervisor in the Visible property of an admin button or a screen. The named formula stays in sync because it depends on the User() function.

Troubleshooting: If fxUserRoles returns <empty>, check that the Dataverse tables are correctly related and that 'Primary Email' matches the email from User().Email. The LookUp filter must be delegable – use an exact match.

4. Parsing URL Parameters with Default Values

Deep links can pass parameters like a record ID or a debug flag. The Param() function reads these values, but if a parameter is missing, you get Blank(). Named formulas let you supply defaults and bundle all parameters into one record.

Assume your app is launched with a URL like:

https://apps.powerapps.com/play/...?assetId=A003&source=email&debug=true

Define:

fxUrlParams = {
  AssetId: Param("assetId"),
  Source: Coalesce(Param("source"), "Direct"),
  DebugMode: Lower(Coalesce(Param("debug"), "false")) = "true"
}

Now use fxUrlParams.AssetId to load a specific asset, fxUrlParams.Source for analytics, and fxUrlParams.DebugMode to conditionally show diagnostic controls. If source isn’t in the URL, Coalesce supplies “Direct”.

5. Referencing Environment Variables in a Single Place

Environment variables in Dataverse let you store configuration values like admin email or company name. Instead of repeating the LookUp everywhere, combine them into one record.

Add the Environment Variable Definitions and Environment Variable Values tables to your app. Then:

fxEnvVars = {
  AdminEmail: LookUp(
      'Environment Variable Values',
      'Environment Variable Definition'.'Display Name' = "Support Email"
  ).Value,
  CompanyName: LookUp(
      'Environment Variable Values',
      'Environment Variable Definition'.'Display Name' = "Company Name"
  ).Value
}

Every control can use fxEnvVars.AdminEmail or fxEnvVars.CompanyName. If the environment variable changes, the formula recomputes the next time it is referenced – no need to republish the app.

6. Centralising Colour and Font Definitions

Hard‑coding colour codes (ColorValue("#198754")) makes theming and updates tedious. Collect all colours and fonts into a themed record that you can reference as fxTheme.Primary or fxFont.Body.

fxColor = {
  Primary:   ColorValue("#0d6efd"),
  Secondary: ColorValue("#6c757d"),
  Success:   ColorValue("#198754"),
  Danger:    ColorValue("#dc3545"),
  Warning:   ColorValue("#ffc107"),
  Info:      ColorValue("#0dcaf0"),
  Light:     ColorValue("#f8f9fa"),
  Dark:      ColorValue("#212529")
};

fxFont = {
  Heading: Font.'Open Sans Bold',
  Body:    Font.'Open Sans',
  Sizes:   {
      H1: 24,
      H2: 20,
      Body: 14
  }
}

Now set a label’s Color to fxColor.Primary and its Font to fxFont.Heading. If the brand colour changes later, update one place and all controls reflect the new colour.

Common mistake: Forgetting that named formulas cannot contain side effects. You cannot put Set(fVar, ...) inside a named formula – keep them pure.

Final Recommendation

Named formulas shine when you need the same computed value in multiple places and you want to avoid variables or repetitive code. They make your app more maintainable, reduce the risk of stale data, and keep logic centralised.

Start small: convert one repeating gallery filter or a user profile lookup. Once you see how neatly they work, you’ll likely adopt them for environment variables, theming, and URL parameters as well.

References

• Original article by Matthew Devaney: 6 Use-Cases For The Power Apps App Formulas Property
• Microsoft Learn: Overview of named formulas in Power Apps (placeholder – verify exact URL)
• Microsoft Learn: Delegation in Power Apps