Point the Excel Online (Business) connector at a blank sheet and ask it to add a row, and the flow fails before it does anything useful. The connector doesn't write to cells or sheets. It writes to a named Excel table, and that table has to already exist inside a workbook that's already sitting in OneDrive for Business, SharePoint, or an Office 365 Group. Microsoft's own connector reference is direct about this. The workbook must exist in advance, and the connector cannot create a completely new workbook from scratch.
That single requirement trips up more builds than any throttle or row limit further down the flow. Someone sets out to create an Excel file from Dataverse records, pictures one flow that pulls the data and produces a finished report, and instead spends an afternoon working out why the add a row action keeps returning an error about a table it can't find.
What the connector needs before it writes anything
Excel Online (Business) sits in the Standard tier of Power Automate connectors, so it doesn't need a premium licence. Microsoft's licensing documentation confirms Standard connectors are available to users on free plans and to anyone holding a Microsoft 365 licence, though Microsoft still caps Standard connector activity at 25,000 actions per day at the tenant level.
Once you're past licensing, the connector gives you a fixed set of actions and nothing outside them. You can add a row into a table using the current AddRowV2 action; the older AddRow action is deprecated. You can update a row, though the update only overwrites the cells you specify and leaves blank columns untouched. You can delete a row or fetch one by key column, and if more than one row happens to match that key, only the first match gets updated or deleted, which matters more than it sounds like it should when your key column isn't as unique as you assumed. You can list rows with filtering, sorting, and pagination, create a table or worksheet inside a workbook that already exists, list the tables and worksheets already in a file, and run Office Scripts against the workbook through the Run script action.
Create table and Create worksheet come closest to building something from nothing, and both fall short of it. Create table adds a table to a workbook that's already there. Create worksheet adds a tab to a workbook that's already there. The workbook itself is never the connector's to make. Office Scripts can build a new file outright, but that means writing and maintaining script logic that sits outside the standard actions Microsoft documents for this connector.
Before any of this runs, build in a short wait after the workbook is created or copied. Microsoft's troubleshooting guidance for this exact error recommends a delay, something like 30 seconds, between copying or creating the workbook and the first action that touches it, because a file that isn't fully initialised won't show its tables to the flow yet.
The row and size ceilings that show up later
The connector carries hard limits that aren't something a Power Platform admin can raise. Microsoft's own documentation puts the maximum size of a single connector request at 5 MB, and the workbook itself can't exceed 25 MB. That 25 MB ceiling is specific to Excel Online (Business). Its sibling connector, Excel Online (OneDrive), built for personal Microsoft accounts rather than organisational ones, caps files at 5 MB instead, according to the same documentation.
Throttling sits on top of the size limits. Microsoft documents 100 API calls per connection per 60 seconds for Excel Online (Business), and the same number applies to the OneDrive connector. Push past it and you get a 429 error, and Microsoft's guidance for handling it is to add explicit delays around connector actions rather than retry aggressively. A workbook can also lock itself against updates or deletes for up to 6 minutes after the connector last touched it, stretching to 12 minutes on the OneDrive connector, which matters if you're chaining several add-row actions back to back and wondering why the second one stalls.
Reading rows back has its own default. List rows present in a table returns up to 256 rows unless pagination is turned on, and Microsoft's documentation doesn't give a hard ceiling for how far pagination can go once it's enabled, only that it's required to retrieve everything beyond that first page. The same action tops out at 500 columns before you need to name the extra ones explicitly in the Select Query parameter.
None of this affects a flow that appends a handful of rows a day. It becomes a problem once real volume runs through a single connection, where the throttle and the file lock start triggering errors that don't show up at low volume. That's the situation our piece on generating documents in volume covers in more depth.
The native Excel template route in Dynamics 365
Dynamics 365 has its own answer to this, sitting in the Document templates section next to Word templates. You can build one from the Power Platform admin center for the whole organisation, or from an individual record for personal use, and the finished template lands in Azure Blob storage by default, or in a SharePoint folder if you want it editable later.
Microsoft's documentation on Excel templates records a maximum of 50 records exported into the template file during that creation step. Fifty. If your dataset runs to thousands of rows, the template you're designing against is built off a thin slice of it, not the whole thing.
That limit is narrower than it first sounds, because it only governs template creation. The same documentation confirms that when someone later uses the finished template to export, every row in the selected view comes through, with no 50-record cap in sight. The limit shapes what you see while designing the layout. It has no bearing on what the template pulls once it's built and someone runs it against a live view.
That still matters for design work. Formulas and formatting built against a 50-row preview can behave differently once a real export runs to a few thousand rows, particularly if the layout assumes patterns that only appear further down the dataset. Templates support formulas, pivot tables, and charts, and Microsoft's own guidance is to put new content above or to the right of the data table, and to write formulas against table column names and named ranges rather than fixed cell addresses, so extra rows don't overwrite that work later.
A few other constraints round this out. Templates have to be built and edited in Excel Desktop rather than Excel Online, because changes made in the browser version are lost the moment the tab closes. Pivot chart data doesn't refresh automatically when the file is opened, by design, since auto-refreshing could expose data the current viewer isn't meant to see. Images embedded in a template can cause errors during analysis operations. And a template only works inside the environment where it was downloaded, so moving one from a sandbox to production means rebuilding it, not migrating it.
Exporting straight from a Dynamics 365 view
Export to Excel, run straight from a view, defaults to 50,000 records, a figure that comes from Microsoft's Finance and Operations troubleshooting documentation. An admin can raise that default, and Finance and Operations technically allows configuration up to a million rows, but Microsoft's own guidance says not to push past 100,000, and warns that even 100,000 can cause memory problems depending on the environment and how complicated the grid is.
Separate Microsoft documentation, covering static worksheet export in model-driven Power Apps, puts the working ceiling at 100,000 rows at a time rather than 50,000, and its documentation for dynamic worksheet export and PivotTable export carries that same 100,000 figure. These aren't one number measured twice. They're different export mechanisms in different parts of the product, each with its own documented cap, and the research doesn't reconcile them into a single answer because Microsoft never built them as a single feature.
Static worksheet export comes in two forms. One captures the full view across every page. The other, limited to whatever's currently on screen, matches the default of 50 rows per page in a model-driven app list. Dynamic worksheet export goes further, keeping a live connection back to Dynamics 365 so the data refreshes inside Excel, with each refresh authenticating the user and trimming results to what they're actually permitted to see.
None of this is built for large pulls. Microsoft's own troubleshooting documentation states plainly that Export to Excel isn't intended for large-volume data extraction, calls it memory-intensive, and warns it can cause out-of-memory errors and server unresponsiveness once the row limit is pushed up. For anything approaching a real bulk export, the same documentation points toward data management instead, specifically the data management framework and the data import and export framework, because those tools are built to move volume without loading the entire result set into a browser session first.
What none of these routes handle well
Formatting is the weak point across all three, just not in the same way. The connector can't apply conditional formatting through its actions at all; that needs formulas or an Office Script. It can't create charts either, for the same reason, and pivot tables aren't supported at all, because of a limitation in the underlying Graph API, according to Microsoft's own connector documentation. Export to Excel from a view is more limited still. No custom formatting, no formulas, no conditional formatting during the export itself, though a static worksheet does carry over the column order, sort order, and column widths from the view that produced it. The Excel template is the only one of the three built to hold formulas, pivot tables, charts, and multiple sheets, which is why Microsoft designed it as a separate feature rather than an extension of ordinary export.
Data types cause their own problems regardless of which route you pick. Currency fields export as plain numbers with no currency symbol, so formatting them as currency afterward is a manual step. Number columns lose their group separator. A date and time field shows as a date-only value in the cell, even though the underlying data still carries the time component, and Microsoft's documentation notes that viewing that data through the Excel add-in shows it in UTC rather than local time, because the add-in talks directly to the database rather than through the app's regional settings. Locale mismatches between a machine's region settings and the organisation's configured language and format settings can shift or misdisplay data when a dynamic worksheet refreshes, so it pays to confirm those two settings actually agree before trusting a refreshed number.
If what's actually needed is a formatted workbook produced directly, without hunting for a pre-built table or working around a 50-record preview, none of these three routes fit. That calls for a way to generate a fully formatted workbook directly instead of bending one of them into that shape.
Match the route to what happens after the file leaves the flow. A report someone opens and reads calls for the Excel template, since it's the only one of the three built to carry formulas and charts without extra scripting. A flow appending rows to a shared tracking sheet throughout the day calls for the connector, with the table already built and the pace kept under a hundred calls a minute. A real bulk pull, the kind built for an audit or a migration, calls for data management rather than either of them, because Export to Excel was never built to move that much data without running out of memory first.