Managing and Exporting High-Volume Datasets (~1M Records) in Power BI

Hi Sidhant 

Both of the approaches you’ve tried are valid directions, but each comes with its own limitations that explain the issues you’re facing. With the paginated report route, simply using visibility rules on columns often fails because while the report view might hide them, many export renderers (especially Excel and CSV) still output all columns regardless of visibility, which is why users keep seeing everything; the more reliable method is to build the dataset dynamically (for example through a stored procedure that returns only the selected columns) so that the export itself contains exactly what was chosen. On the Fabric side, your “Bad Request” errors usually stem from mismatched authentication or payload—Fabric APIs require a proper Azure AD token and very specific endpoint formatting, which Power Automate doesn’t automatically handle unless you set up a service principal or OAuth flow. Best practice for handling 1M+ rows is to avoid pushing them through Power BI visuals or standard exports at all: instead, use paginated reports with dynamic datasets if you need user-driven exports, or better yet, trigger a Fabric pipeline that writes the selected data to OneLake/ADLS in Parquet/CSV and then share the link or notify the user via Power Automate. In short, paginated reports are fine for “ad-hoc but smaller” exports when you control the dataset, while Fabric pipelines are the scalable option for very large datasets; both require careful parameter handling and correct authentication, and often the cleanest pattern is a hybrid—parameters from Power BI or Power Automate passed into a Fabric pipeline that generates the extract on demand.