Patch in Forall failing to update

[lmheimendinger]

I have been wrestling with trying to update a collection.  Let me describe the problem I am trying to solve.

I have a SharePoint list that has one record corresponding to some buttons that I will use in various Power Apps.  Based on user shared access to other Power Apps - each button corresponds to a different app - I want to update NOT THE LIST but a collection created from the list.  Why? Because multiple logons for the same or differnt apps that use the list could run at the same time.

Here's what I do:

1. ClearCollect(col1, SharePoit list) - get list into collection
2. ClearCollect(col2, coll1) - get a copy to use in ForAll
3. ClearCollect(colSeq,Sequence(CountRows(col1))) - get a sequence of integers 1 to number of rows in list
4. Set(varSeq, Sequence(CountRows(colNavigate))) - variable as an array

In the list and col1 and col2, the IDs all start at 1 and increase by 1 for all rows, so the ID matches the sequence array.  There is also another column for the list and collections called ButtonID which is an integer that corresponds to the ID (but is just a number column with 0 decimal places).  The reason for the sequence, I thought, was that in the ForAll I could by trimming the first row of the array it would always match the collection row in ForAll.  Apparantly that works as in testing I create an array row containng the sequence number and buttonid and they match.

Here is then what I try to do:

ForAll(col1,
   Patch(col2, LookUp(col2,ThisRecord.Title=Title, {UserOK:TestPermissions.Run(varUser,'App ID').result}));
   Remove(colSeq,First(colSeq))
)

The Power Automate is a flow that tests each app ID passed to it (in the SharePoint list and collections) and returns a "Yes" or "No" text to indicate if the user has shared permissions for that app.  I can look at the run history for that flow and see that it is successful and returns the desired value for each row in the list.  But the collection never gets updated.

I have tried other values in LookUp() all of which were equally unsuccessful, such as ID=ID or Title=Title or ButtonID=ButtonID.  I thought ID=First(colSeq).Value would be the thing I actually want but get  a type mismatch of Number = Table.

Why do this?  I want a gallery to have a list of allowable buttons displayed (along with other data), so filtering the gallery toonly include UserOK = "Yes" makes this a snap if I can figure out how to update the collection for the gallery.....

I realize I am probably doing something stupod, but what?

[RandyHayes]

@lmheimendinger 

To start, your formula has the ForAll backward. You are trying to use it like a ForLoop in some development language - which PowerApps is not.  ForAll is a function that returns a table of records based on your iteration table and record schema.

It is more efficient to use the function as intended and will provide better performance.

Also, trying to look at the For All as a ForLoop is causing you to chase your tail trying to make it work like one...as I am guessing you are feeling at this point be trying this and that to deal with so many duplicates of collection tables and trying to index it with another.

My first suggestion beyond that is to modify your flow to accept a list of apps rather than just a single app.  The reason for that is, most ALL function in PowerApps accept tables as parameters (ie. Patch in this case).  If you have a flow that only handles a single record, then you are forced to use the ForAll backward and then the flow has to be instantiated over and over again.  This is excessive use of your flows and also a performance hog!

Not entirely understanding your source data and the need for sequences and ID's that match the existing ID, but without that your formula can be changed to:

ClearCollect(colAppList,
    ForAll(SharePointList,
        {
        Title: Title,
        'App ID': 'App ID',
        UserOK: TestPermissions.Run(varUser,'App ID').result
        }
     )
)

This would provide a collection (in memory database table) of the list apps and the permissions for the users.

If you are not planning to alter the records in memory in your app, then you can skip the collection and just assign to a variable:

Set(glbAppList,
    ForAll(SharePointList,
        {
        Title: Title,
        'App ID': 'App ID',
        UserOK: TestPermissions.Run(varUser,'App ID').result
        }
     )
)

I hope this is helpful for you.

[lmheimendinger]

A lot to parse but thanks and I will advise on progress or failures.  

Question: in the Set(gblAppList,....) sugesstion, that should result in an array, right?  I still have the problem of using the results to filter the gallery.

Question:  what exactly do you mean by "backwards" use of ForAll?  Am I incorrect to believe that as I have used it, it iterates though col1 (which is identical to col2) but the Patch operates on col2 as a corresponding row?  I know I can't Patcvh col1 in the ForAll which is why I duplicated it in col2.

[RandyHayes]

@lmheimendinger 

When you say array...there really is not that in PowerApps...it is a table.  And so yes, glbAppList would be a table.  Tables can be in variables.  Those tables can be used on any component that needs a table (like your gallery).

Oh the ForAll - one of my favorite functions in PowerApps (when used properly) as it is the most powerful data tools in the arsenal of functions!

ForAll is a function that returns a table.  The structure is ForAll(table, {record definition})  So the table is the table that ForAll will iterate over, the record definition defines what the schema of the returned table will be.

Example:

ForAll(Sequence(10), {MyCol: Value + 5})

In the above, the table to iterate over is a table (returned from Sequence) that has a single column called Value.  We want our ForAll to iterate over that and create a table with records that have a MyCol column that contains the Value of the Sequence-returned table plus 5.  

One very important thing to keep in mind is that if you do NOT specify a record structure, PowerApps will automatically create a Value column.

So, for example:  ["a", "b", "c"]  will produce a table with a single column called Value (because nothing was specified.  It is equivalent to:  Table({Value: "a"}, {Value: "b"}, {Value: "c"})  (but you can see the shorthand is quicker if you are good with a Value column)

Likewise, if you use a ForAll with no record definition - ex: ForAll(["a", "b", "c"], "X") This will produce a table with three rows that have a single column called Value with a value of "X"

Why I say that is...when you use the ForAll backward, it is still creating a table, you just are wasting the output of it.

It's like putting a 2+2 in an action formula...PowerApps will still evaluate it to 4, but since you are not assigning it or using it...it is wasted.

When trying to use ForAll as a ForLoop (which it will mimic because it technically iterates over things), you will quickly come to hate it because that is not what it was designed for.  You cannot do things in it like in a ForLoop because (hopefully now obvious) you can't impact the source iterator while you iterate over it.  Plus, if you are putting "statements" in your ForAll rather than record information, then each is returning values that are being added to a Value column in the ForAll record...and then wasted!  This ALL contributes to added and unnecessary overhead in your app.

I just wish that they would modify the docs on PowerApps to NOT have examples that use the ForAll backward!  It gives people the WRONG impression on how to use it.  And since many developers flock to PowerApps with the developer mindset...the first thing they are looking for is "where's the for loop function?" - They find the ForAll and think "That's it!".  Quickly things go wrong!

But the biggest obstacle is the collections and the duplication of collections.   Keep in mind that each one is just a copy of the data over and over.  There is no need for all that overhead in the app.

A collection should ONLY be used in scenarios where you need to add/remove or update records in a table in memory. (or if you are building an offline app...where you do need in-memory database ability).  

You'll see that the last formula I provided uses no collections.  It produces a table of records (you can see the records structure in the ForAll) into a table that is stored in a variable (because it most likely does not need to be add/remove/updated later on in the app).  

Hopefully this all makes sense and is helpful for you.  I can go on and on about ForAll usage and Collection usage in PowerApps because they are probably one of the top two things that are misused in the platform and contribute to people doing much more work than is necessary in their design process.