How to count the number of items in a collection ?

[axellefevre]

Hi,

There is a function to count the number of items which are in a collection?

Thanks.

[Meneghino · Accepted solution]

Yes, CountRows(MyCollection)

All functions are here:

https://powerapps.microsoft.com/en-us/tutorials/formula-reference/

[Anonymous]

Any better answer so far? I am facing the same difficulties? how to count items in gallery?

[Fier]

In case you missed it like I did in the accepted answer: use the following "CountRows(CollectionName)"

[Anonymous]

I used this "CountRows(CollectionName)" in my gallery but it returns only 100 records out of 909. 

Please help! 

[poweractivate]

@Anonymous 

What is your data row limit set to? This is located under Settings -> General 

The default is 500. The max is 2000. It may have even been changed to 100.

 Now let's suppose you even set the max to 2000 records.

Well, if you use CountRows(Gallery1.AllItems) - it doesn't matter!

A Gallery loads items 100 at a time,

so therefore CountRows will likely return, at most 100 items. 

While a Gallery's Items property may sometimes be a way to help with issues like this, it does not work too well for CountRows in particular, since Galleries count at most 100 items at a time, even if the data row limit is at the max of 2000!

Note that Collections (e.g. ClearCollect, Collect), variables (UpdateContext, Set), and in general, just any functions at all, that are not specifically delegable themselves, are subject to the data row limit. This is even if there is no yellow triangle warning shown.  Note that the CountRows function itself is generally not a delegable function. Therefore, it's subject to the Data row limit, whether or not a yellow triangle warning is even shown.

In your case, you have 909 records. I would recommend you just raise the data row limit to the max of 2000 and just use CountRows(DataSourceName) directly on the data source, and you should get 909 as the count!

In terms of what do you do if you have more than 2000 records and want to count them. There are multiple possible approaches depending on the data source. To keep it simple for now, I won't elaborate on this, and would suggest you the simpler solution above for the moment @Anonymous .

[Anonymous]

Thank you for your reply! 

I'm currently building a Payroll and Attendance for HR department, we're in a factory of 1200 people therefore we'll have rougly around 1200 rows per day, so I don't expect to be able to accurately count even using Power Automate as those only allow up to 5000 rows. Thanks, I guess I will have to do count and filter for specific dates or just won't be counting at all then. 

[poweractivate]

@Anonymous 

It is possible to count beyond 2000 records in Power Apps, or even beyond 5000 records. However the approaches are somewhat advanced, even complex, to do this, and I feel like it may be still like that even to this day.

I might check on it (if I have time) to see if I could offer some guidance on this subject, in case it helps you. There are also working approaches out there you could look for and discussed before multiple times, however, they are somewhat complex and advanced. I may consider to consolidate these approaches in some step by step guides, or even attempt to investigate some approaches not considered before to make this easier for someone who wants to do this kind of counting the number of records, on a scale beyond 2000 Records or even 5000 Records, on a regular basis. 

Out of curiosity, which data source(s) are you using now? For example, is it SQL, Dataverse, SharePoint List, or something else? It is possible to count beyond 2000 records with any of those data sources - but I am curious which you are using now @Anonymous .

Could you also give some info what kind of counts you prefer, is it the total count, or filtered by something like a date as you are saying?

Indeed if you can get the total count to 2000 or less records using things like a delegable Filter function for example (and have the data row limit set at the maximum of 2000), that is certainly some of the first ways you could look at to address this issue. In some advanced use cases these methods are not enough, but in a large number of cases, these approaches are somewhat effective and also tend to help you gain greater understanding of the data and what you want to accomplish with that data in the short and long term, so your thinking seems to be on the right track here. Since these approaches help gain understanding of the data itself, I would recommend to start with these approaches anyway first, as you seem to be doing, since trying to use things like a delegable Filter function to get the number of records below the data row limit, and after that using non-delegable functions like CountRows, are some of the best things you could try first, and I recommend you to try them first.

[Tazui]

I'm currently using Sharepoint List as source data. 

I also have access to Dataverse for Teams but for some reason building inside team hasn't been a great experience for me though. Would you recommend Dataverse for Teams instead of SP List?

[poweractivate]

@Tazui @Anonymous I'd recommend to keep the SharePoint List for now in general without an overwhelming reason to change over to Dataverse. You probably have a lot set up there and changing over should be carefully planned over some period of time. Also, I feel like it would be better to use Dataverse than Dataverse for Teams if possible.

Note that CountRows is still not delegable even in Dataverse, and to my awareness it is not even delegable in data sources where more delegable functionality is supported than even Dataverse ( i.e. CountRows is likely not delegable even in the SQL Server Connector for example), so that CountRows alone is also not necessarily the best reason to move out of SharePoint List to Dataverse, as it remains non-delegable even after the switch of the data source.

While there may be benefits of switching to Dataverse, and while Dataverse may offer more versatile options in general and there are more delegable operators and functionality in Dataverse than SharePoint List, trying to use CountRows there won't be one of the benefits of switching to Dataverse. So for the moment, I might recommend you to keep the SharePoint List. It is also possible to count beyond 2000 rows, and even beyond 5000 rows, in the SharePoint List as well, if using some specific approaches (while may be advanced, it should be possible) so it may be better for you to keep the SharePoint List at the moment.