2 reasons for not using Named Formulas in Power Apps

When Named Formulas first came out, I very much liked the idea of using them. However, I have found that there are a few reasons for not using them.

Named Formulas

In my introduction post about Named Formulas I described the general idea of them.

In general, Named Formulas will reduce the amount of code that you need, however a reduction in code doesn’t always mean that your app will be better or performing faster.

Reason 1 – Performance and Named Formulas

Imagine that your Named Formula reads data from a data source. You might even apply some heavy filtering and sorting.

Now every time your app updates that data source with for example the Patch function, your Named Formula will potentially be updated again and again. If you use the Named Formula on every screen then you might be ok, however if you have any screens that don’t use the Named Formula then your app might end up reloading many times.

Some of the apps where I implemented Named Formulas initially, started to perform less and less well. Part of this could be that the amount of data has increased and it could be that Named Formulas have been ‘improved’.

When I used a named formula to sort out sorting of a collection, while in my app I updated the MyData collection as shown below, I found that my app started to perform a lot less well. Where Named formulas would change long running operations to take double as long or more to execute.

2 reasons for not using Named Formulas in Power Apps
2 reasons for not using Named Formulas in Power Apps 1

Especially when the named formula is used in a gallery (in other words, the named formula is actively displayed on my screen), the performance of the app becomes a problem. Using just classic collections remained a lot faster.

Reason 2 – Code that is used once

To take the complex code away from the various screens in your app, and place it in a single place might sometimes look attractive. However it can only mean that the Named Formula will update itself at any time when the underlying data changes.

For example, if the following Named Formula is used only in a dropdown on a single screen, while MyData is used everywhere, then there is no need to use a Named Formula.

nf_colSortedDataOnScreen1 = Sort(
    Filter(
        MyData,
        Status = 'Status (MyData)'.Active
    ),
    mySortField,
    SortOrder.Ascending
);

Concluding thoughts

Recently I’ve seen a number of apps, where named formulas have been overused. Cleaning this up can improve the general experience within an app.

User Defined Functions ( this feature is currently not GA yet), are fairly similar to Named formulas as the complex code in the app can be moved to a central place, ready to be reused. User Defined Functions however will only be executed when they are called. Therefore they give better control.

So when should we use named formulas?

  • Static data or semi static data (Such as branding)
  • Fast data operations, that are used everywhere

However, don’t just place all code into the named formulas, because it may feel right for one part of your app.


Discover more from SharePains

Subscribe to get the latest posts sent to your email.

Related Posts

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.