Improving the efficiency of this ForAll Formula

[Alastair]

Hello Everyone

I have created a ForAll formula that finds processes related to each Property that the user has selected.  This formula works as intended however I feel is not as efficient as it could be.  This is because for each selected Property it has to refilter the entire Property Processes list, i.e. search through the whole list again for a single value.  The commented formula I am currently using is below.

This is a bit of an open-ended question as I'm interested in any and all ways to improve the efficiency of the formula.  One thing that I think would improve the efficiency but Im not sure how to implement, is to Filter on all selected Property values at the same time instead of doing it one at a time. (I.e. checks whether each Process in the SP list is related to any of the selected Properties).

For clarity, what I mean by efficiency is how long the formula takes to finish running

[Pstork1]

The real problem here is that Power Apps is a declarative application rather than a procedural one.  The ForAll() function isn't an actual loop and is therefore quite inefficient.  The best way to improve that efficiency is to pass the task off to a procedural application.  That's where Power Automate comes in.  As a workflow engine this is the kind of work that Power Automate is designed to do.  You can easily pass the collection to a flow as a JSON array, process it in Power Apps, and then return the results and store them as a collection.

[Alastair]

Thanks for the answer.  Power Automate does make sense as a better solution.   Are there any potential hiccups with using Power Automate?  I'm slightly cautious in using it for this scenario, as I'm expecting the function will be called frequently by simultaneous users.  

[RandyHayes]

@Alastair 

As @Pstork1 mentions, you will not get a lot of gain in performance with the ForAll for large operations.

Once slight advantage is to actually use the ForAll as it is intended rather than a For/Loop in development as it is not.

So, the ForAll produces a Table...you should use it.

ClearCollect(varPropertyProcess,
    ForAll(varProperties,
        Filter('Property Processes',
            Property.Value = SelectedProperty.Title &&
            (IsBlank(SelectedYear) || SelectedYear = Year)
        )
    )
)

A couple of things though:

1) Your collection is going to be a table with a single column called Value that will have a table of duplicated items based on the Filter for the iterations of the varProperties collection.

2) You will increase your performance in your app by not using collections as they must gather all their data in these type of formulas.  You would be better off working directly with the datasource object rather than duplicating what is already a duplicate of the duplicated cloud session table that is a duplicate of the real data source (get the idea of how much duplication goes on?)

2) Your Year statement in the Filter appears to have an incompatible type.  I am not sure where and what SelectedYear or Year are in your formula, so I can not add any advice to that.

You would be better off, as mentioned, working with the datasource directly and to include this filter as part of that process.

The farther you stay away from behavioral actions like you have, the better your performance will be and the less work you will have to do.

I hope this is helpful for you.

[Alastair]

Thanks for your response.  

For the Year its comparing string to int is why its blue.  Easy enough to resolve once the rest of it comes together.  

Im very much interested in avoiding the use of collections where possible to improve performance, however this is how I've always done it, so I would appreciate a bit of guidance on where to start. 

For the  varPropertyProcesses collection I use the collection to both display each process returned in a gallery and to generate a pie chart of there statuses. The collection is there so I only have to filter down to the records I care about once and then send the result to both. Is it better to filter twice and run directly off the SP datasource or is there an even better way to go about it? 

[RandyHayes]

@Alastair 

Ah, you need one of my favorite "dynamic variables".  

Let's take a short explanative journey first to explain what that means - grab some popcorn!

Collections:

A collection is way overused (and unfortunately what everyone demonstrates their formulas with).  A collection is an in-memory database.  It is a Table.  It has the ability to add or remove rows to the table.  That is all it brings to the party.  Collections must be filled with information.  This results in a duplicate of the original information. Collections are "glorified" variables in that they have the add/remove ability, but, just like variables, they are a Snapshot of data at the time they are collected.  They do not change unless you change them (which is just more overhead for your app).

Collections are good for two things - when you are designing an offline capable app, or you NEED the ability to easily add or remove rows.

Variables:

A variable can be anything - text, number, boolean, Table, record, etc.

We can leverage the Table aspect of this by using a variable rather than a collection when we don't need the add/remove rows ability - this reduces overhead on the app.   

Variables are snapshots of information at the time they are assigned.  They do not change unless you change them.

PowerApps

PowerApps is built around the concept of Excel.  You use formulas in Excel to calculate values. Once you have values in cells (either by formula or by hand) you then reference those cells to build additional calculations or results in other cells.  You do NOT set variables to the cell value so that you can then reference the variable value in other cells...that would be too complex - and so too it is in PowerApps.

In PowerApps, you reference results as much as possible. 

Until now, the above (collections and variables) are very programmatic in nature.  PowerApps is a no-code design platform, not a development platform.

So..."Dynamic Variables"

The concept is simple following the Excel concept.  If you set a Label, for example, to something like a LookUp column result, then you can reference that Label text property from anywhere in your app.  Plus, if it is based on a datasource, then it will simply change as the datasource changes (the dynamic part).  So, if I set the text property of the label to : LookUp(datasource, ID=1, Title) then the label will show the Title value for the record with the ID of 1.  If, in the app, I change the Title with a form, or a patch or update or anything else, then that label value will change automatically (just like changing a value in your Excel cell will change the cells that have formulas based off of it).   

This concept can be used all over your app to first, reduce the amount of duplication of your formulas, but also to reduce the amount of work you have to do to maintain that value.  It is all dynamic.

Dynamic Table Variables

So, the above is great for simple values like text and number and boolean is great, but (as in your case) you want to have a table of records for a Gallery and the same Table of records for a chart.  How to do that??

Well, there is a little know process for doing this in PowerApps.  It comes from a Datacard.  Not a form datacard, but a Canvas datacard.  If you add a scrollable screen to your app, you will get a Canvas control.  In that Canvas control will be a Datacard.  You can cut and paste the entire canvas control from that screen (and get rid of the screen if you want) in order to paste it into a place that you would like in the app.  The Canvas will be invisible (Visible : false).  It can be sized small and out of your way as well.  There is ONLY one thing you want in that - the datacard.

Reason being, the DataCard has a property called Update - it is a Record property.  The Update property can be anything you want.  And, in this case, we're going to make it a table (actually a record with a table).

So, in the Update property a formula such as this:  LookUp(datasource, ID=1)  The datacard will now have an Update property that is the FULL record of the lookup.  You can reference this from anywhere : datacardname.Update.Title will produce the Title column value for the record.  If the record is changed in your app...so too will the Update property automatically change.

Now...the Table (because that is what you want for a Gallery and a chart).

If we set our Update property to something like this:  {Items: Filter(datasource, criteria)}

We will now have a dynamically changing "variable" in the app.  You can reference the table from the Items property of the Gallery as such :  datacardname.Update.Items and the same for the chart.

You could even shape that update property even more with things like:

{Items: Filter(dataSource, criteria), chartData: Filter(..etc..)}

Now we have two columns in the Update property record that can be referenced and will be dynamic based on changes in the app.

This completely eliminates the need to have behavioral actions to build collections and variables just because you know that the data has changed.  Very often see people doing a Patch on a record and then recollecting their entire collection again from the datasource to "keep the app up-to-date".  With the "dynamic variable" there is no need...the Update property will already have its new data and you can just reference that as needed.

Anyway, that is the basics of it.  One day I will get the opportunity to complete the video I have on this concept, but for now, the above pretty much describes it.

I hope it is clear and helpful for you - it just might change everything for you in how you design your apps!

[Alastair]

The Dynamic variables sound really good.  Just a shame that Microsoft decides to hide really powerful functionality so you have to jump a few hoops to get the component you want.  Will take a crack at getting a proof of concept working for both Dynamic variables and Dynamic Table variables so I can understand how they work fully.   

I do have two questions about Dynamic variables though.  

1. Are there any issues with Dynamic variables (& table variables) when used within large lists.  One of my lists is around the 90,000 record mark.  
2. Are they just as useful when used in conjunction with the Dataverse? Are they still needed? With the above we're looking to move to Dataverse in the near future.  
3. Is there a place where I can find your videos?  

[RandyHayes]

@Alastair 

Yes, they are powerful.  I believe that Microsoft and others stick with the bare essentials when describing what to do.  It's reminiscent of when listening to a presenter present a function in a technology and preface it with "Now you wouldn't really do this, but I am doing it to demonstrate quickly."

Your questions:

1) The dynamic variables are as limited as much as your record limit in your app and the ability to delegate your criteria.  If you can delegate criteria and you can have results to that criteria that are less than the record limit in your app, then you are just as fine with them as anything else.  If your actual results are over the record limit, then you will need to explore a more complicated approach (and also you'll need to ask yourself why you would want to return that many results to a user in a PowerApp).  

2) Yes, just as useful with any DataSource.  The DataVerse datasource is just like any other.

3) Yes, look at my signature line below...it has a link to my videos.

[Drrickryp]

Hi @RandyHayes 

I am fascinated by your use of the datacard to hold a table and have now used it in my apps with great results.  Have  you made the video on this?  I would love to see it and any extensions of the concept. 

[ngohw]

absolute game changer -- reduced process times by over 90% alongside another implementation i had that adds threading to ForAll. thank you for this!