Travel Light: When Dataverse List Rows Stops at 250
The 250 that wasn't
I recently had a flow that needed every row from a Dataverse table. Nothing fancy: a List rows action, no filter, no row count, then loop through the results. The table had well over 250 rows in it. The flow ran fine, no errors, all green checkmarks.
It returned 250 rows. Exactly 250.
That's the kind of number that makes you squint. If it had been 247 or 312, I might have shrugged and assumed the table was smaller than I thought. But a nice round number like that usually means something upstream decided to stop, and it wasn't me.
If you're staring at a suspiciously round row count right now, here's what I found and what fixed it.
What I expected vs. what I got
According to the documentation, List rows should hand back up to 5,000 rows by default when you don't turn on pagination. So 250 wasn't a documented limit I'd forgotten about. It was something else.
I checked the usual suspects first:
Filter rows was empty, so nothing was being filtered out.
Row count was empty, so I wasn't accidentally capping it.
Security roles were fine, since I could see all the rows in the model-driven app.
After some digging, the pattern that kept showing up was this: when you don't tell List rows which columns you want, it grabs all of them. And "all of them" in Dataverse is a lot more than you think. Turns out the size of each row was the problem, not the number of rows.
The fix: pack light
I only needed two columns, so I told the action to only bring back those two. That's it. Next run, every row came back.
Here's how to do it:
Open your List rows action.
Expand Advanced parameters (or Show advanced options if you're in the classic designer).
Find Select columns.
Enter the columns you need as a comma-separated list, with no spaces. Something like:
cr123_name,cr123_status
A few gotchas I bumped into along the way:
Use the logical name, not the display name. "Project Name" won't work. You need the schema-style name like cr123_projectname. You can find it in the table's column list in make.powerapps.com, under the column's properties.
Pay attention to the case. Logical names are all lowercase. It matters.
Lookups are sneaky. For a lookup column, you'll usually need the _columnname_value format (for example, _parentaccountid_value) to get the ID back.
Your dynamic content shrinks. Once you set Select columns, later steps only show those columns in the dynamic content picker. If something you expected is missing, this is the first place to look.
So what's actually going on?
Don't freak out if this sounds alien. The short version: List rows has a size budget, not just a row budget, and fat rows burn through it fast.
When you see a Dataverse table in a view, you might see eight or ten columns. Behind the scenes, every row carries a lot more:
System columns like Created On, Modified By, Owner, Version Number, and a handful of others you never added.
Formatted values. A choice column comes back as both the number (100000001) and the label ("Approved"). Dates come back raw and formatted. Currency gets its own extras.
Lookup annotations. Every lookup returns the ID, the display name, the table it points to, and more.
OData metadata, the little @odata.etag-style tags that ride along with each row.
So a row you think of as "a name and a status" can easily be 50+ properties in the JSON that comes back. Multiply that by a few thousand rows and the response gets big.
Power Automate has message size and content throughput limits to keep things running. Dataverse's own paging docs also note that some tables might return fewer rows per page than the 5,000 default. When the response is heavy, you get a smaller first page and a next link pointing to the rest. If your flow isn't set up to follow that link, the rest of the rows just... don't show up. No error. Just fewer rows.
I'll be honest: I couldn't find Microsoft documenting "250" as a specific number. But the behavior lines up, and the fix confirms it. Trim each row down and the whole set fits on the first trip.
Picture every row as a backpack. Let Dataverse stuff it with everything it owns and it gets heavy fast, and you don't get very far. Empty it out, put back only what you actually need, and suddenly you can move.
Belt and suspenders
Select columns fixed my flow, but it's not a guarantee for every table size. If your table keeps growing, a few more habits help:
Turn on pagination. In the List rows action, go to Settings and switch on Pagination, then set a Threshold higher than the number of rows you expect. Power Automate will follow those next links for you. (Note: this doesn't apply if you're using a FetchXML query. That one has its own paging rules.)
Check the count. Drop in a quick Compose with length(outputs('List_rows')?['body/value']) and run it once. If you get a suspiciously round number, you've hit a page boundary.
Look for the next link. In the run history, open the List rows output and look for @odata.nextLink. If it's there, there are more rows waiting.
Filter at the source. If you only need some of the rows, use Filter rows in the action instead of grabbing everything and filtering later. Less data in, faster flow, fewer surprises.
And honestly, Select columns is a good habit even when nothing is broken. Your flows run faster, the run history is easier to read, and the dynamic content picker isn't a mile long.
Wrapping up
If List rows hands you a tidy, round number of rows and you know there are more, don't assume your data is wrong. Check Select columns first. Tell the action exactly what you need, and it'll usually bring back everything.
Don't feel like this is the only way to handle it. Pagination, FetchXML paging, and filtering all have their place. But for a quick "why am I only getting 250?" moment, trimming the columns was the easy-peasy fix for me.
I hope this helps someone out there battling a similar scenario.
Try. Fail. Learn. Repeat.
Comments