dropdown got delegation warning

[twister]

Hi, How do I solved this warning on dropdown selection? My record only got 700++ and I have already set the limit to 2000

Thanks

[RusselThomas]

Hi @twister ,

Dropdowns and ComboBoxes work differently in terms of how they query the source.  ComboBoxes have an additional "Search" capability, so the actual query going to the source is a Search() function.

This means, you will always get the Delegation warning with ComboBoxes that have search enabled for sources that don't support Search() as a delegated function.  If you don't need the "Find Items" capability of a combobox, then you can disable this by setting the IsSearchable: property to false and you should see the delegation warning disappear - if you do need it however, then you will be stuck with the delegation limitation (on a ComboBox anyway).

The other alternative is to use a dropdown, or build your own "dropdown" using a text input and a small gallery, but instead of being tied to the builtin Search() of a combobox, you can instead use the Filter() function.

Kind regards,

RT

[twister]

thanks for info but I also got delegate warning on App maybe due to deep linking function? What is the problem exactly? I have no idea on this warning..

[RusselThomas · Accepted solution]

Hi @twister ,

It's just a warning - you will always get it when you increase the default data row limit size.  You can choose to ignore it, but you should know the implications of doing so.  You won't get rid of the warning unless you set your limit back down to 500.

The intent behind this setting is to limit and minimize data transfer wherever possible - apps, especially mobile apps, are not supposed to be transferring huge amounts of data around.   Imagine you run the equivalent of a "Select * from" against a SQL table that contains terabytes of data from a mobile device?  Not ideal.  

Mobile Apps (and in fact, most apps) should be very picky about the data they transfer, and should always aim to be highly performant and optimised from a data perspective, only fetching what is required.  PowerApps especially is a connection-based tool - it does not (primarily) store data in the app, but relies on data stored in data sources - therefore, traffic between the app and the source is of primary concern.

Optimisation is usually achieved by building queries that support filtering and refining data at the source so that your app just receives the data it needs for your user to consume/interact with.  These queries are effectively "delegated" to and executed by the source.

Queries (or sources) that don't support delegation behave differently and this behaviour can negatively impact your user experience dramatically.

There are two key problems that arise with non-delegable queries or sources;

1. Accuracy
2. Performance

To try and illustrate this, let's assume you're applying some sort of filter query to a SPO list that has 10 000 rows in it.  Based on your filter, you're expecting 10 rows to come back from your query.

The 10 rows you're looking for are sitting inside your 10 000 row dataset as follows;

• 1 is found within the first 500 rows of the 10 000
• 4 are sitting somewhere between row 501 and row 2000 
• 4 are sitting somewhere between row 2001 and row 6000 
• 1 row in sitting somewhere between row 6001 and 10 000

Consider this delegable example with a data row limit of 500;

1. You run a query to SPO using a delegable filter function.
2. PowerApps sends the query to SPO
3. SPO runs the filter on the entire dataset of 10 000 rows and only returns your 10 rows of data that match the filter. 

10 rows are returned from the query.  This is the correct result and the one you want.

When you send a non-delegable query from Power Apps to the source, PowerApps replaces it with the equivalent of

FirstN(yourDataSource, n)

where 'n' is your configured 'data row limit'.

The source will therefore just dump/return the first n rows.  No filters and no refinement get applied when this happens, so you will just get the first 500 rows of your data. 

PowerApps will then apply your original non-delegable query against that subset of data now sitting in your app session. 

This means you would be pulling more data than you need, potentially slowing down the user experience and (for mobile devices) incurring unnecessary data costs, and on top of this you could be getting inaccurate results because your query is being run against an incomplete data set. 

Consider the same example as above with a non-delegable query;

1. Same SPO list with 10 000 rows in it.
2. You run a query to SPO using a function that is non-delegable, but you still expect the same 10 results to come back.
3. PowerApps asks SPO for the first 500 rows of data.
4. PowerApps then applies your expression to the 500 row dataset that was returned and finds 1 result.

So instead of finding 10 results from the full 10 000 checked, you're now only getting 1 result from the first 500 checked.  On top of this, instead of just getting 10 rows back from SPO, PowerApps is getting 500 rows, and still returning an inaccurate result.

Consider the non-delegable response if you increase your row limit to the max, 2000.

1. SPO still ignores the filter expression and returns the first 2000 rows of data.
2. PowerApps then runs your filter expression on the dataset that was returned and displays 5 results instead of 10.

Once again, instead of just getting 10 rows back from SPO, PowerApps has to get 2000, and then it still doesn't provide you with an accurate result because there are only 5 rows matching your query within the first 2000 rows of your data.

The intention with data row limits and being able to increase them is not so you can suck in bigger datasets to run non-delegable queries against - it's there mostly to increase the size limit of valid data returned - i.e. something that your source has already filtered (so let's say instead of 10 results, you were expecting to find 600 - PowerApps would have capped the returning result at 500 thanks to the data row limit - increasing it can resolve this issue).  Increasing this can still slow down your app though - hence the warning, so do it with care.

Kind regards,

RT

[twister]

very nice of info with example..very2 clear and appreciate it..