Power Apps Delegation and Row Limits Explained: Visual Guide to 500-2000 Record Limitations
2023.12.21
I was struggling to fully grasp the relationship between delegation and data row limits (default 500 rows) in Power Apps. However, after creating visual diagrams, the concept became much clearer. Here are my notes on the subject.
We’ll work with this list in Power Apps, where I’ve reduced the data row limit to “5” for easier understanding. Note: After changing the data row limit settings, you need to restart the App Designer
Understanding Delegation
First, delegation means letting the data source (in this case, SharePoint Online list) handle data filtering and sorting operations instead of Power Apps.
For example, when you apply a filter that can be delegated to a SharePoint Online list, the filtering is performed on the SharePoint side, like this:
In contrast, when you apply a non-delegable filter (Note: for SharePoint Online list ID columns, only the “=” operator supports delegation), Power Apps needs to retrieve all data first and then apply the filter on its side, like this:
While this concept of where the data processing occurs (delegation) is relatively straightforward, it becomes more complex when the “data row limit” setting comes into play.
Data Row Limit
The data row limit is a value that can be configured in “App Settings” and represents the amount of data that Power Apps can process locally.
I visualize this setting as shown in the diagram below, like a checkpoint that only allows through the amount of data specified in the settings.
As explained in this article, even when trying to store large amounts of data in a variable, you cannot store more data than the “data row limit” allows.
And when this “data row limit” combines with “delegation”, things get quite complicated…
Patterns Where Expected Results Are Not Achieved
So, I’ve identified several patterns where the interaction between delegation and data row limits prevents us from getting our desired results.
Pattern 1: Delegation Works but Hits Data Row Limit
For example, if we apply this delegable filter to our SharePoint list:
Filter(SharePoint_List_Name,Num＜7)
It results in the scenario shown in the diagram below, where even though delegation is possible, some data (in this case, the item with ID 6) is missing due to the data row limit.
This is how it looks when executed in Power Apps:
Pattern 2: Non-Delegable and Hitting Data Row Limit
When we apply this non-delegable filter to our SharePoint list:
Filter(SharePoint_List_Name,ID＜7)
It results in the scenario shown below, where we don’t get the desired results (the item with ID 6 is missing).
Here’s how it appears when executed in Power Apps:
Pattern 3: Within Data Row Limit but Non-Delegable
When we apply this non-delegable filter to our SharePoint list:
Filter(SharePoint_List_Name,ID＞7)
Although it might seem like it should work since we’re only looking for three items (IDs 8, 9, and 10), due to the non-delegable operation, the behavior is as follows:
And we don’t get the correct results:
Pattern 4: Partially Delegable Operations – Case 1
When we execute a partially delegable operation (where only SortBy is delegable) on our SharePoint list:
In conclusion, when working with SharePoint lists and you want to:
Store data in variables
Perform aggregations
Display data in list boxes
You need to carefully consider both “delegation” and “data row limits” to ensure proper functionality.
Bonus: Special Behavior of Galleries and Data Tables
However, Gallery and Data Table controls are special cases. If the operation is delegable, they can display data beyond the “data row limit” (in this case, 6 items).
This is likely because these gallery controls have “lazy loading” capabilities, meaning they can perform multiple data retrievals of the “data row limit” amount to display all data (at least, that’s my understanding).
Note that even with these controls, if the operation is non-delegable, they cannot display data beyond the “data row limit”.
コメント