A Power BI Dataflow is a cloud-based ETL (Extract, Transform, Load) capability within Power BI Service that runs Power Query M transformations against source data and stores the output as structured tables in Azure Data Lake Storage Gen2 — making the prepared data available for any Power BI report in the same tenant to consume without repeating the transformation logic. Where a standard Power BI report embeds its data preparation logic inside the .pbix file’s Power Query Editor — meaning each report independently connects to the source, applies transformations, and stores the result in the report’s in-memory model — a Dataflow moves the transformation to the Service level, executes it on a schedule, and produces a shared, versioned output table that multiple reports import from. The Dataflow is the Power BI equivalent of the ETL layer in a traditional data warehouse architecture: a governed, reusable transformation that produces a single prepared dataset consumed by many analytical outputs.
Dataflow Architecture
| Component | Function | Location |
|---|---|---|
| Dataflow definition | Power Query M transformations and source connections | Power BI Service Workspace |
| Computed entities | Transformations that build on other Dataflow entities (requires Premium) | Power BI Service (Premium Workspace) |
| Output storage | Transformed table data stored as CDM (Common Data Model) files | Azure Data Lake Storage Gen2 connected to tenant |
| Refresh schedule | Independent refresh cadence — Dataflow refreshes before downstream reports | Power BI Service scheduler |
| Consumption | Power BI Desktop connects to Dataflow as a data source; imports prepared tables | Power BI Desktop Get Data → Power BI Dataflows |
Why Dataflows Matter for Finance BI
In GCC enterprise finance BI deployments where multiple reports consume data from the same source — the Oracle EBS general ledger, the Oracle Fusion AP subledger, or the Oracle FCCS consolidation output — without Dataflows, each report developer independently connects to the source, applies the same cleansing and transformation steps, and stores the result in their report’s model. When the source changes — a new fiscal year, a chart of accounts addition, a currency change — every report’s transformation must be updated individually. With Dataflows, the transformation runs once in the Dataflow, and all reports consuming it benefit from the update automatically on their next refresh. The governance and maintenance efficiency of Dataflows scales with the number of reports consuming the same source data.
Dataflow Limitations
Power BI Dataflows have two significant limitations that BI architects must plan for. First, Computed Entities — Dataflow entities that perform transformations on the output of other Dataflow entities, enabling a staging-and-integration layer — require Power BI Premium or Premium Per User licensing. Without Premium, each Dataflow entity must connect directly to a source system, preventing the layered ETL architecture (staging → integration → presentation) that characterises mature data warehouse design. Second, Dataflows do not support incremental refresh of individual rows without Premium; in Power BI Pro, a Dataflow refresh always re-processes the entire dataset, making large-table refreshes slow and limiting the practical frequency of Dataflow refresh for high-volume ERP sources.
What Goes Wrong in Practice
The most common Dataflow implementation failure is a Dataflow that is not refreshed before the reports that consume it. When the Dataflow refresh and the report dataset refresh are scheduled independently — and the report refresh runs before the Dataflow refresh completes — the report imports stale Dataflow output from the prior refresh cycle. The report appears to have refreshed successfully (it did — from the last available Dataflow data) but the data is a cycle behind. Dataflow refresh must always complete before dependent report dataset refreshes are triggered; this sequencing must be explicitly configured in the refresh schedule, not assumed to happen in the right order by default.
How Loop Wise Solutions Designs Dataflows
We implement Dataflows using a three-layer architecture — a staging layer (raw source data as loaded), an integration layer (cleansed, standardised, and conformed), and a presentation layer (business-friendly dimension and fact tables ready for report consumption). This layering, combined with computed entities where Premium licensing allows, provides the closest cloud-native equivalent to a governed data warehouse transformation layer.
