Count Condition Update

[Anonymous]

I'm getting a delegation error with the below.

Is there anything I can do to fix this issue?

Also, how can I update the condition to include 'count only those Parks with the name "blahblah', rather than counting all Parks?

Better yet, add the following to the below 'and count only those Parks that match the content of ComboBox1'.

CountIf(ParkSnapShotDetailList,ECPark="Yes")

[Pstork1]

You can't get rid of the delegation warning because CountIf() isn't delegable.  However, if you use a delegable function to pre-filter the data being counted to get it below the threshold then you can ignore the delegation warning.  See the example below

CountIf(Filter(ParkSnapShotDetailList, name="blahblah"),ECPark="Yes")

[Anonymous]

Is there a way to make the following work?

     CountIf(Filter(MemberList, Park=ParkAlphaCmboBox.SelectedItems),ECMem="Yes")

[poweractivate]

@Anonymous 

Unless it is really, absolutely impossible otherwise, we would not recommend to ignore the delegation warning for any production scenario for almost any reason, as at some point, the number may just go above the count from the latter part of expression, so it would always be a risky condition that could break at any time. To place outer function that is non-delegable with reliance on the inner function returning less than the delegable limit is currently considered unsuitable for production in our opinion, in 100% of our current production cases, and we almost never even accept to leave it like that for most testing or development purposes either.

We would first recommend try to just use something other than CountIf and just make sure it is delegable in whatever way you can, even if it is ultimately more contrived, as long as it is some way that is delegable it will always be better if it is some other way than by using a non-delegable function. 

That non-delegable outer function composition there on an inner function that returns less than delegable limit and ignoring the delegation warning, should really be the last resort. If you ever resort to it, write it down in a documentation with a big red flag, every time you did this - you will have to maintain that specific part where you used a sub expression to get it down to lower number, because if that sub expression ever goes past the delegation limit, that will make it not work properly anymore, and there will be no warning after that in production, it will just start missing records. For this reason, we do not ever leave delegation warning there, and not even for one production use case. 

Also remember to do one more thing if you really must go this way - in App Settings for the app you do this with, you should raise the default non-delegable limit from 500 to 2000 - you'll need it - and it won't be nearly enough in many production cases, even the max of 2000. The magic number is 2000 because that is the highest the  App non-delegable limit setting will allow, even if you change it, but the default is 500, you may want to raise it to 2000.

As for what that specific function would be which would be delegable in your scenario, that may depend, what is your current data source right now - is it SharePoint List? Please confirm this in next reply and if we can we might check into the delegable version of the specific function for you that would count all the parks that meet specific condition, or any equivalent way that might avoid pitfalls of simply ignoring the delegation warning.

[Anonymous]

Thank you for the detail.

Yes, SP list.

What else counts other than 'Count...'? Not sure how this can be accomplished. I'll look around for alternative.

Thank you.

[Pstork1]

If the ParkAlphaCmboBox is a multi select rather than a single select you are going to have a problem with the filter.  Otherwise, that should work as long as the Filter gets you below the data row limit (500 default, 2000 max)

[Anonymous]

I'm already at 2000.

I'm using the following, or a version thereof based on content desired, in four TextInput fields. 

The are all returning '0'.

Circling back on the 'never ever CountIf', is there another condition that counts that won't kick back the delegation error that I can try?

[Anonymous]

Also, the Member List will NEVER exceed 2000 items, so my assumption was this straying from the known delegation norms could be achieved with little to no adverse impact.

Thanks!

[poweractivate · Accepted solution]

@Anonymous 

---

@Anonymous wrote:

Also, the Member List will NEVER exceed 2000 items, so my assumption was this straying from the known delegation norms could be achieved with little to no adverse impact.

---

If that is the case, then maybe it's because of this in your screenshot:

ParkAlphaCmboBox.SearchText

Unless there is typed text in the ComboBox, this will be blank by default, hence the zero.

Try a simpler model first like an Input Text Field. See if it works. Then adjust the ComboBox one if it has to be ComboBox.

If you can truly guarantee what you said about the 2000 never being exceeded for the member list - then @Pstork1 suggestion will work for you, even in production. (and technically, you have to guarantee it only for the non-delegable outer part, if you do that carefully, it can be even more, as @Pstork1 mentioned as well)

Check if above helps. 

We are also checking if your scenario is possible with delegation only in some other wild way, still keeping SharePoint List (if it even is possible).

[poweractivate · Accepted solution]

@Anonymous 

There is a solution to do it with delegation.  We share with you here in case you are interested.

By the way, by delegation, we mean it for real, we tested with a super low delegation limit of 1 set on the App. Because actually even if the yellow triangle doesn't show, it may still be using a non-delegable function under the hood, the only way to be sure, is set delegation limit to 1, have more than 1 matching item for the Filter, and have way more than 1 total item as well (which we tested with).

When we tested with delegation limit of 1, we actually could confirm by testing that even the most basic Filter formula against SharePoint List, with just something equals something else - the most basic supported Filter -  would be actually non-delegable under the hood when using it directly - yes, even that most basic one. 

The solution to make it delegable, is to place that same Filter formula in Items property of a Gallery first and then just CountRows on that Gallery. This is the only way we could find that works. Otherwise, even the most basic Filter turns out to be non-delegable - even when we got it to show no warnings and even when we did not use ANY counting functions, even then it was returning 1 record in our case instead of 4 until we did it this way! 

You could also obviously just have the Gallery show all items and have CountRows against the Filter in the Gallery from somewhere else like a Text field, this works too, but this is less ideal to do it this way as the Gallery would load all the records first in memory and could overfill with too much, potentially affecting performance negatively - you would circumvent the delegation limit and get all the records to display in the Gallery. but with big penalty. Imagine that huge scrollbar on that Gallery (and that would still be there with all those tons of records, even if you made the Gallery Invisible)!

Because the Filter simply just works properly in the Items Property of the Gallery itself ,  it is better to put it there with the Filter ,then just CountRows on all the records after that, as the Gallery itself will properly filter with delegation and have the lower number of records as well, not all the records, which could be orders of magnitude better for performance than loading literally all the records in a Gallery first. You can just make the Gallery invisible if you want, the Gallery is just to get this to work - because it only works doing this in a Gallery when we tried it.

Note that our test should check out. Our delegation limit is 1. If it was non-delegable, we should not have been able to get more than 1 record at most (which happened during testing many times such as when using a Collection, which does not throw a warning but this is a non-delegable technique too - it even returned only one record, when using the Filter directly just to get the Table of records - when it was not in a Gallery and without using CountRows - the Table itself had just one record every time!), and actually, it would not have seen more than 1 record in the first place, so it was more likely to return zero. Only in Gallery, we got it to return 4 records in our test on a delegation limit of 1.

Here's details:

SharePoint List:

App:

Solution Summary:

In the Items Property of a Gallery:

Filter(List01,ParkName=TextInput1.Text)

In the Text Property of a Label:

CountRows(Gallery1.AllItems)

And finally, if the Gallery is not needed for UI, just set Visible to false for the Gallery.

Check if above helps you @Anonymous