Power Platform Community Forum Thread Details

I'm working on a PowerApp that will have a huge amount of data stored in a SharePoint List (10s of 1000s of records over time). One way of addressing this is to divide the lists into different geographic locations. The other way is to have one list for all entries. My concern is with dealing with delegation and reporting issues. I'm looking for some advice on design best practices.

Should I have one list for all entries and use nest filtering or other best practices to view the data?
1. PRO - Minimal manipulation of the PowerApp needed.
2. CON - Difficulty viewing the info in app and reporting using PowerBI.
Should I split the SharePoint Lists by geographic location?
1. PRO: SharePoint List size would be much more manageable.
2. CON: More complex PowerApp code. (I've only found one way of pointing to different SP Lists, and that is using a SWITCH statement).

I've been out of the PA space for a while, so there is a lot that I don't know. Please offer any suggestions or design best practices.

Categories:

Power Apps Pro Dev & ISV

Hi @GH-05021942-0,

If you have a Text field for the geographical location, then a query on that field is Delegable (if you use equals or StartsWith), so the list can be initially "pre-filtered" with that, really negating any advantage of smaller lists per location. Also having alternate data sources in any given query can in itself be a challenge, so the one list is probably the better option. I have lists and libraries over 100k records and have no issue with Delegable queries (though a bit of data structure planning is often needed).

The one issue you need to address for lists over 5k is to index (in SharePoint) any fields involved in queries.

Please click Does this answer your question if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider giving it a Like.
MVP (Business Applications) Visit my blog Practical Power Apps LinkedIn