Back in September 2022, Power Apps named formula was released as an experimental feature, eventually becoming generally available (GA) in November 2023. Named formulas are a great addition to Power Apps, allowing us to increase the performance, scalability & maintainability of our apps. They work very similarly to variables or collections, whereby we can define an object or value once and use across our app.
In this article, I’ll walk through how they work and include some good use cases for using named formula instead of collections or variables.
I’m sure I’m not alone when I say that I’ve abused the OnStart property of a canvas app. Since 2016, I’d add all sorts in there, then wonder why users would experience a 5 minute wait time for their app to load. So then I’d “be creative” and move some or all the Power Fx to a OnTimerEnd property of a timer control. This would be for things like capturing user data, loading collections and storing calculations; anything the user needed for their app session. These would usually be stored in variables – the irony of storing static data in something that’s meant to vary 😂
I wish Power Apps named formulas were around sooner. It helps makers and more experienced Power Apps devs to move away from bloating OnStart. We can use named formula to make the points of reference we need, once, then consume them where needed across our app. They are also kept up to date real-time, meaning we don’t need to reset variables or rebuild collections – they’ll be done for us!
We got useful insight when Power Apps named formulas were first released, with this comprehensive release note from Microsoft. However, whilst building a chess board in a canvas app is cool, it’s not the reality on the ground for most makers.Â
Location
The first key bit of information is where do find Power Apps named formulas? Well, fittingly it’s in the same place as OnStart. When editing an app, select App then you’ll find Formulas in the property drop down.
Naming convention
I’m still trying to settle on what I consider a good naming convention for Power Apps named formulas. My initial thoughts were to continue using existing prefixes for variables, collections etc. These would be consistent with the rest of the development.Â
But how could another maker decipher what is being defined where? Keep in mind that named formulas do not show up under the variables section. Tracing their origins could be hard then:
If I have a dedicated naming convention for named formulas, anyone else taking on my development will instantly know what they are, and therefore where they’re defined.
My standard variable prefixes for a while have been gv (global variable), cv (context variable) and tv (temp variable when using the With function), so I did wonder if nv would be a good prefix for named. But then they’re called named formulas, not named variables. Maybe nf is a better prefix then? I’m still undecided, but for the purposes of this article we’ll go with that.
Example data
For the Power Apps named formula examples I’ll walk through shortly, I’ve added the following data.
1- A list of onboarding tasks as a Dataverse table, with 3 items:
2- Both the environment variable related Dataverse tables, and the Office 365 Users connector:
Use cases
Let’s look at some common use cases we’d typically find in the OnStart property of an app. I’ll walk through how to transition these across to named formulas.
Before we do, just a very small tip – all named formulas must end with a semi-colon. Even if you only intend on having a single formula defined, it MUST end with a semi-colon. This confused me momentarily when first using them, though the formula bar does give us a pretty good error message:
Logged on user info
If you’ve followed my blog for a while, you’ll know I recommend using the Office 365 Users connector over using the User function. Retrieving the logged-on users Active Directory profile information and image is a solid candidate for moving to a Power Apps named formula:
// Get logged-on user object
nfLoggedOnUser = Office365Users.MyProfileV2();
// Get logged-on users profile image
nfLoggedOnUserImg = Office365Users.UserPhotoV2(Office365Users.MyProfileV2().mail);
As you’d expect, you can define a named formula then reference it to define another one. With that in mind, we can improve the above Power Fx to this:
// Get logged-on user object
nfLoggedOnUser = Office365Users.MyProfileV2();
// Get logged-on users profile image
nfLoggedOnUserImg = Office365Users.UserPhotoV2(nfLoggedOnUser.mail);
We can also reference our named formula outputs for properties of other controls. In the image below, I’ve a label with the text property set to nfLoggedOnUser.displayName and an image with the Image property set to nfLoggedOnUserImg:
Counting records
A typical design might be to set a variable to calculate the number of rows in a collection or data source. Using our Onboarding Tasks table, I can capture the number of rows at a specific point in time – the time of execution. Let’s count how many rows have ‘Ongoing’ in the Task Status column:
Set(
gvNumberOfActiveTasks,
CountRows(
Filter(
'Onboarding Task Lists',
'Task Status' = "Ongoing"
)
)
);
However, if that value needs to be updated during a users session, I’d have to run that code again to keep the value current. I can’t re-run any code from OnStart during an app session, so the code would need to be moved elsewhere. There may then be times where code is duplicated in order to capture latest values.
However, a named formula keeps itself up to date, which is super cool! The configuration is the same filter logic as above:
// Count of active tasks
nfNumberOfActiveTasks = CountRows(
Filter(
'Onboarding Task Lists',
'Task Status' = "Ongoing"
)
);
Let’s update the status of one of our tasks to completed. Note how the global variable doesn’t update as the Power Fx needs to be run again. Whereas, the Power Apps named formula automatically reduces by one to reflect the change:
That is EPIC! No more duplicating code, or moving OnStart logic to hidden buttons or OnVisible properties. Use a named formula instead and let the app do the hard work.
Building collections using data sources
A nailed-on candidate for named formula is building collections, especially for reference data that will never change within a user session. We’d do this in canvas apps to prevent looking back to a raw data source for entries, instead caching the data as a collection to improve performance. The trouble is, if your app has 100’s of reference tables your Power Fx in OnStart, OnVisible or other behavioural properties starts getting a bit mad. This could be a list of departments or a static list of onboarding tasks.Â
// Build collection of static onboarding tasks
ClearCollect(
colOnboardingTasks,
'Onboarding Task Lists'
)
As a named formula, the Power Fx is very similar:
// Build table of static onboarding tasks
nfOnboardingTasks = 'Onboarding Task Lists';
As you would expect, nfOnboardingTasks is referenced in the Items property of a gallery in the same way any other tabular data source is:
Building collections manually
There may be times when you don’t have a list or table storing reference information. You need to hardcode something manually in your app instead. This could be things like tables or collections for navigation menu’s:
ClearCollect(
colStarWarsMenu,
{
Name: "Luke Skywalker",
Screen: 'Screen 1'
},
{
Name: "Darth Vader",
Screen: 'Screen 2'
},
{
Name: "Chewbacca",
Screen: 'Screen 3'
}
)
We can move this scenario to Power Apps named formulas, like so:
nfStarWars = Table(
{
Name: "Luke Skywalker",
Screen: Screen 1'
},
{
Name: "Darth Vader",
Screen: 'Screen 2'
},
{
Name: "Chewbacca",
Screen: 'Screen 3'
}
);
Theming
One of the most common ways to apply theming config is to have it all defined in Power Fx and loaded up when the app starts. Another thing to move away from OnStart and into a named formula:
// Set theming config
nfTheming = {
colours: {
Cream: ColorValue("#FDF5DF"),
Teal: ColorValue("#5EBEC4"),
Pink: ColorValue("#F92C85"),
Grey: ColorValue("#2B2B2B")
},
font: {
Style: Font.Lato,
Size: 14
}
};
Getting environment variable values
Environment variable values are also highly unlikely to change mid-session. Again, these are values we’d typically load in the OnStart property as a variable. Here, I have an environment variable relating to Star Wars and I want the current value:
Set(
gvStarWarsEnvVar,
LookUp(
'Environment Variable Values',
'Environment Variable Definition'.'Schema Name' = "new_StarWars"
).Value
)
Moving to a named formula is done so with the following structure:
nfStarWarsEnvVar = LookUp(
'Environment Variable Values',
'Environment Variable Definition'.'Schema Name' = "new_StarWars"
).Value;
Referring back to my Environment Variables article, I suggest a way of retrieving the values using Power Automate. This removes the need to add the two Dataverse tables to your app, which of course means Premium licensing all round. This method relies on calling said Flow directly from within the app. Unfortunately this can’t be currently done using Power Apps named formulas so please keep that in mind.
So which do I use now?
So where should we put my Power Fx now? Moving forward, I’m likely to operate a very simple rule of thumb:
If there’s reference data that will never change during a users app session – named formulas.
If there’s reference data that will change during a users app session – OnStart and/or other behavioural properties such as OnSelect, OnVisible etc. Even then, we can still use named formula for these too (as per the ‘Counting Records’ example above), but depends on the requirements.
What we do need to be mindful of though, is not simply moving everything from OnStart to named formulas. Whilst the latter only runs when needed, we don’t just want to shift any issues from one area to another. Review your code, plan what to use and where based on how users will interact with data.Â
Have you started using Power Apps named formulas yet? What are your experiences so far? If you have any scenarios you’re not sure about for when to use them, feel free to leave a comment below and I’ll do my best to help!
Thanks for reading. If you liked this article and want to receive more helpful tips about Power Platform every week, don’t forget to subscribe 😊
This is a great blog post as always. Really nicely explained. Thank you Craig !
Great article!
Another excellent blog post and thanks for sharing
Yes, Named Formulas are really great for the main reason of “unbloating” the AppOnStart. Another use case for me has been in Date calculation to use in an Office Attendance App I built. I had to calculate the Date for each Monday and the Next Monday so I hold them in an nfVariable (stealing our convention here) and then referencing them in the App when required. Extremely useful.
That’s a great shout, Douglas. I’d thought of date based scenarios being a good thing to put in the article but I forgot if you’re happy to share your Power Fx logic, I’ll update this article to include it.
Hey Craig,
this is a great article. I always wondered – and never managed – how to fill collections in Formulas. Your approaches bith make a lot of sense and I will give them a try in the future.
Fortunately the variable overview received a “Named Formulas” section in the meantime.