5 Best Practices for Power Apps Named Formulas

Quite a few of my recent posts have been about Power Apps named formulas. In this post I’m going through some of the best practices.

Named Formulas

A mentions in my previous posts named formulas can improve your app’s performance. However there are quite a few best practices that you should consider following when you develop named formulas in your Canvas apps in Power Apps.

Best Practice 1 – Name your named formulas

Personally, I always prefix my named formulas with the letters “nf”. Now if you want to use “nf_” or any other variation is fine of course, but it is important to be able to differentiate between a global variable, a context variable and a named formula.

Best Practice 2 – Group your named formulas

Once you add 100s of named formulas to your app, it can become coding nightmare moved from all over your app to a coding nightmare in a single property.

// Settings in the app
nf_fontsize = 13;
nf_primarycolour = Color.Red;

// Menu
nfmenu = [ { Label: "Home",
             Screen: "Home Screen"},
           { Label: "New Case",
             Screen: "New Case Screen"},
         ];

// Queries from SQL database
nfRecordQueryResult = DropColumns(
    AddColumns(
        Table(sql_dev.dboSelectAllMyRecord(
            { Area: nfArea, 
              Email: nfUserEmail
            }
        ).ResultSets.Table1),
        R_ID, Value(ThisRecord.Value.R_ID),
        R_Description, Text(ThisRecord.Value.R_Description)        
    ),
    Value
);

By grouping the various named formulas it makes finding back that one named formula that you can’t remember its name of so much easier. Now grouping code will help a bit but we can take this a bit further. Comments are going to be our friend!

Best Practice 3 – Add comments

Adding comments (see earlier example), is also important. Ideally a comment between every group of

named formulas, and a comment before each individual named formula can really help. now a format like the ones below can really help documenting your code.

/////////////////////////
// Settings in the app
/////////////////////////

// base font size used for text
nf_fontsize = 13;

// colour of text used within the app
nf_primarycolour = Color.Red;

/////////////////////////
// Next group of settings
/////////////////////////

...

Best practice 4 – Don’t reference controls

Within named formulas it is possible to reference to reference controls that live on screens. So typically you could use this to filter data by using the values selected in for example dropdowns as shown in the code below.

nfMainScreenGalleryItems = 
Search(
    Search(
        Search(
            Filter(AddColumns(nfRecordsQueryResult, ID, Text(R_ID)),
                R_Category = cmbHomeFilterCategory.Selected.RL_Value || IsEmpty(cmbHomeFilterCategory.SelectedItems) || IsBlank(cmbHomeFilterCategory.Selected.RL_Value)
            ),
            txtHomeFiltersSearch.Text,
            R_Description,
            ID,            
            R_Categories,
        ),
        cmbHomeFiltersOwners.Selected.Result,
        R_Owner,
        R_Groups
    ),
    cmbHomeFiltersBU.Selected.RL_Value,
    R_BusinessUnits
);

However , as named formulas are always updated when you need them ( read use them), you will find unexpected results if your forms haven’t been loaded yet. Now this isn’t a problem when you are developing your app, but when your users use the app in a browser then form/screens/controls may not be loaded yet.

The easiest way to avoid this is to, set a variable when the value of your dropdowns change and ensure that that variable is always set, avoiding any unexpected results.

Best Practice 5 – Don’t nest filter queries

When creating named formulas, it is easy to just copy code that you created in your app. Where within your app it might make sense to run the following code with 5 nested search, filter and AddColumns actions. For named formulas this isn’t the best option.

nfMainScreenGalleryItems = 
    Search(
        Search(
            Filter( AddColumns( nfRecordsQueryResult, ID, Text(R_ID)),
                R_Category = varCategory)
            ),
            varHomeFiltersSearch,
            R_Description,
            ID,            
            R_Categories,
        ),
        varHomeFiltersOwnerSearch,
        R_Owner,
        R_Groups
    );

Why is this not the best option? Let me first give the better code:

nfDataWithColumns = AddColumns( nfRecordsQueryResult, ID, Text(R_ID));

nfDataFiltered =  Filter( nfDataWithColumns ,  R_Category = varCategory));

ndDataSearch1  = Search( nfDataFiltered,
            varHomeFiltersSearch,
            R_Description,
            ID,            
            R_Categories,
        );

nfDataSearch2 = Search(ndDataSearch1,
        varHomeFiltersOwnerSearch,
        R_Owner,
        R_Groups
    );
              

So why is separating the named formula better? Imagine if the varHomeFiltersSearch variable in the above examples is updated then we will find that only ndDataSearch1 and nfDataSearch2 are re-evaluated. When we nest all the functions into one named formula the whole named formula is rerun.

Further thoughts

As named formulas become a more and more important to make slow apps perform better, organising a lot of your code just within one property is quite a challenge. It would be nice if we could make these named formulas modular somehow. Other than using comments in the Formulas property, I haven’t found a suitable solution for this yet.