If you do not need to edit or add items to your data but are using the list for lookups only, I suggest that you save your data as a static Excel file and use the Import from Excel option for datasources. Admittedly, it has limited application but in the right circumstance, you can import up to 15,000 items at a time. It creates the datasource in seconds, delegation is not an issue, all functions are possible and they operate at blinding speed. You can even create huge collections from the data by combining the tables using Collect().
For an example, please see my post in the community blog Automatically-Prefill-City-and-State-using-Zip-Codes-in-your-App It uses a zip code file consisting of over 40,000 items broken into three 15000 item tables and then reconstitues them into a single collection.
I appreciate that suggestion. Unfortunately, all of these datasources will be regularly updated. I would much prefer to store them in Excel and will continue thinking over your suggestion, but the regularity of the updates makes me think this might not work.
If you need to update then this is not the right approach. If you will have large datasets (greater than 2-4k), consider migrating to Sql or Common Data Service.
Hi @pwrappr01 ,
I have a working solution to grabbing all items in SharePoint. If you follow the thread convo between me and Randy it will answer a ton of questions asked here:
This solution requires either Flow or Workflow Designer to accomplish this task. With this solution I am able to pull in as much or as little as I want through iterations.
Hi @PhilD ,
No advantages that I can think of. I was working on a list where I was using a customised SNO column and I just used that (missed the point of straightaway using the ID column). My bad!
This solution worked like a charm! Do you have any recommendations regarding performance because this will likely be used on multiple lists with 1,000s of items?
Glad that it worked for you.