Sequential Concurrent ForAll in Power Apps

You may also like...

6 Responses

  1. Rachael says:

    Your code seems to be extremely useful in loading a lot of data quickly into the app, but the premise you list confuses me. You say “ForAll is singular sequential and not concurrent,” which is false. ForAll absolutely does not always run sequentially and it also runs in parallel ‘where able’ according to the documentation.

    You can even test this. I had a case where records were created in the order they should be displayed, so I sorted the galleries by createdon. These records often need to be copied so they can be modified without disrupting the originals, so I have some code to Collect all the necessary records and then ForAll through what was collected to Patch them back in as new records. But the createdon Sort in the galleries no longer worked. These records were sorted by createdon going into the ForAll, but they were not created in that order by the ForAll. In fact, their order was random each time I tried the copy.

    I originally thought ForAll ran sequentially, I was counting on it in fact, but it doesn’t work. Just like Microsoft states; ForAll is not sequential, and it sometimes runs in parallel. In fact, that is their reasoning for taking away extremely useful functions inside the ForAll, like Set or UpdateContext. They don’t want it to be possible to have ordering dependencies. If not for that, there would be no reason to not allow those functions. (I think it’s maddening that they don’t allow them regardless, but that’s a different discussion.)

    • iAm_ManCat says:

      Hi Rachael,

      Apologies for the misunderstanding here, I could have been clearer with my writing – when I wrote singular sequential, I meant singular individually (i.e. it will only process one at a time), and you can see this from the rest of the article as it references that it is Not sequential and that is the reason for creating a method that performs sequentially. I will update the post 🙂

      In terms of concurrency, the reason it states ‘when possible, in parallel’ is because for non-datasource-reliant queries, such as local collections within the App, it can perform concurrently. For anything that actually queries a datasource, it is non-concurrent. This is why this method listed here is still the most performant way of performing a ForAll, and it is absolutely one of the few ways to do so sequentially. You can confirm this by using Monitor to see how it handles queries against a datasource using ForAll. If this has changed for any datasource you are aware of and you have evidence of this, then please let me know and I’ll update the post 🙂


  2. Kevin Ly says:

    I have used same technique to deal with more than 10k records from Dataverse, it takes sometime to load but it is possible to make it running in background while allow user to interact with other contents.
    However, this technique is the last thing we would want to use or all records must be required for apps to run properly. If there is case that does not required all records, it is ultimately must not be loaded into apps. For this practice, I found that filter based on user (account\role\group\permission\role) is one of the best way to get just exact the number of records that user should see.

    • iAm_ManCat says:

      Yes for collecting ‘normal’ data you should not try get large numbers of records, regardless of the formula/approach you are using, as you should be minimizing the data you take into an App – but as I mentioned in the article this is a necessity if you need to take records for use offline or need to handle the storage of many-to-many relationships in a more performant way than a normal ForAll.

      This method can be used for more than just collecting data though 🙂 you can use the Sequential Concurrent ForAll for performant execution of any other action that you would normally be trying to achieve with a ‘standard’ ForAll.

  3. Phil says:

    Cheers for this! I was looking for an approach to do something like this. 🙂 Either to make the Flow concurrent or call multiple flows concurrently. I’d almost written it off – I wasn’t that keen on having mountains of code to do something quite simple, but this is the trade-off. I was going to see if it was possible to ‘tee’ up some hidden buttons and then trigger those in some way, but think this is a better approach, plus is working in my instance.

    • iAm_ManCat says:

      I’m really glad you found it useful – it’s fairly code-heavy but the results have been worth it with larger-scale App performance 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *