Configure and consume a dataflow
With dataflows, you can unify data from multiple sources and prepare that unified data for modeling. Whenever you create a dataflow, you're prompted to refresh the data for the dataflow. Refreshing a dataflow is required before it can be consumed in a dataset inside Power BI Desktop, or referenced as a linked or computed table.
Configuring a dataflow
To configure the refresh of a dataflow, select the More menu (the ellipsis) and select Settings.
The Settings options provide many options for your dataflow, as the following sections describe.
Take ownership: If you're not the owner of the dataflow, many of these settings are disabled. To take ownership of the dataflow, select Take over to take control. You are prompted to provide credentials to ensure you have the necessary access level.
Gateway Connection: In this section, you can choose whether the dataflow uses a gateway, and select which gateway is used.
Data Source Credentials: In this section you choose which credentials are being used, and can change how you authenticate to the data source.
Sensitivity Label: Here you can define the sensitivity of the data in the dataflow. To learn more about sensitivity labels, see how to apply sensitivity labels in Power BI.
Scheduled Refresh: Here you can define the times of day the selected dataflow refreshes. A dataflow can be refreshed at the same frequency as a dataset.
Enhanced Compute Engine settings: Here you can define whether the dataflow is stored inside the compute engine. The compute engine allows subsequent dataflows, which reference this dataflow, to perform merges and joins and other transformations much faster than you would otherwise. It also allows DirectQuery to be performed over the dataflow. Selecting On ensures the dataflow is always supported in DirectQuery mode, and any references benefit from the engine. Selecting Optimized means the engine is only used if there is a reference to this dataflow. Selecting Off disables the compute engine and DirectQuery capability for this dataflow.
Endorsements: You can define whether the dataflow is certified or promoted.
Dataflows can be created by user in a Premium workspace, users with a Pro license, and users with a Premium Per User (PPU) license.
Refreshing a dataflow
Dataflows act as building blocks on top of one another. Suppose you have a dataflow called Raw Data and a linked table called Transformed Data which contains a linked table to the Raw Data dataflow. When the schedule refresh for the dataflow Raw Data triggers, it will trigger any dataflow that references it upon completion. This functionality creates a chain effect of refreshes, allowing you to avoid having to schedule dataflows manually. There are a few nuances to be aware of when dealing with linked tables refreshes:
A linked table will be triggered by a refresh only if it exists in the same workspace
A linked table will be locked for editing if a source table is being refreshed. If any of the dataflows in a reference chain fail to refresh, all the dataflows will roll back to the old data (dataflow refreshes are transactional within a workspace).
Only referenced tables are refreshed when triggered by a source refresh completion. To schedule all the tables, you should set a schedule refresh on the linked table as well. Avoid setting a refresh schedule on linked dataflows to avoid double refresh.
Cancel Refresh Dataflows support the ability to cancel a refresh, unlike datasets. If a refresh is running a long time, you can select the dataflow options (the ellipses next to the dataflow) and then select Cancel refresh.
Incremental Refresh (Premium only) Dataflows can be also set to refresh incrementally. To do so, select the dataflow you wish to set up for incremental refresh, and then select the incremental refresh icon.
Setting incremental refresh adds parameters to the dataflow to specify the date range. For detailed information on how to set up incremental refresh, see the incremental refresh in Power Query article.
There are some circumstances under which you should not set incremental refresh:
Linked tables should not use incremental refresh if they reference a dataflow. Dataflows do not support query folding (even if the table is Direct Query enabled).
Datasets referencing dataflows should not use incremental refresh. Refreshes to dataflows are generally performant, so incremental refreshes shouldn't be necessary. If refreshes take too long, consider using the compute engine, or DirectQuery mode.
Consuming a dataflow
A dataflow can be consumed in the following three ways:
Create a linked table from the dataflow to allow another dataflow author to use the data
Create a dataset from the dataflow to allow a user to utilize the data to create reports
Create a connection from external tools that can read from the CDM format
Consuming from Power BI Desktop To consume a dataflow, run Power BI Desktop and select the Power BI dataflows connector in the Get Data dialog.
The Power BI dataflows connector uses a different set of credentials than the current logged in user. This is by design, to support multi-tenant users.
Select the dataflow and tables to which you want to connect.
You can connect to any dataflow or table regardless of which workspace it resides in, and whether or not it was defined in a Premium or non-Premium workspace.
If DirectQuery is available, you're prompted to choose whether you want to connect to the tables through DirectQuery or Import.
In DirectQuery mode, you can quickly interrogate large-scale datasets locally. However, you cannot perform any additional transformations.
Using Import brings the data into Power BI, and requires the dataset to be refreshed independently of the dataflow.
The following articles provide more information about dataflows and Power BI:
Create and use dataflows in Microsoft Power Platform
- 5 minutes to read
Using dataflows with Microsoft Power Platform makes data preparation easier, and lets you reuse your data preparation work in subsequent reports, apps, and models.
In the world of ever-expanding data, data preparation can be difficult and expensive, consuming as much as 60 to 80 percent of the time and cost for a typical analytics project. Such projects can require wrangling fragmented and incomplete data, complex system integration, data with structural inconsistency, and a high skillset barrier.
To make data preparation easier and to help you get more value out of your data, Power Query and Power Platform dataflows were created.
With dataflows, Microsoft brings the self-service data preparation capabilities of Power Query into the Power BI and Power Apps online services, and expands existing capabilities in the following ways:
Self-service data prep for big data with dataflows: Dataflows can be used to easily ingest, cleanse, transform, integrate, enrich, and schematize data from a large and ever-growing array of transactional and observational sources, encompassing all data preparation logic. Previously, extract, transform, load (ETL) logic could only be included within datasets in Power BI, copied over and over between datasets, and bound to dataset management settings.
With dataflows, ETL logic is elevated to a first-class artifact within Microsoft Power Platform services, and includes dedicated authoring and management experiences. Business analysts, BI professionals, and data scientists can use dataflows to handle the most complex data preparation challenges and build on each other's work, thanks to a revolutionary model-driven calculation engine, which takes care of all the transformation and dependency logic—cutting time, cost, and expertise to a fraction of what's traditionally been required for those tasks. You can create dataflows by using the well-known, self-service data preparation experience of Power Query. Dataflows are created and easily managed in app workspaces or environments, in Power BI or Power Apps, respectively, enjoying all the capabilities these services have to offer, such as permission management and scheduled refreshes.
Load data to Dataverse or Azure Data Lake Storage: Depending on your use case, you can store data prepared by Power Platform dataflows in the Dataverse or your organization's Azure Data Lake Storage account:
Dataverse lets you securely store and manage data that's used by business applications. Data within Dataverse is stored in a set of tables. A table is a set of rows (formerly referred to as records) and columns (formerly referred to as fields/attributes). Each column in the table is designed to store a certain type of data, for example, name, age, salary, and so on. Dataverse includes a base set of standard tables that cover typical scenarios, but you can also create custom tables specific to your organization and populate them with data by using dataflows. App makers can then use Power Apps and Power Automate to build rich applications that use this data.
Azure Data Lake Storage lets you collaborate with people in your organization using Power BI, Azure Data, and AI services, or using custom-built Line of Business Applications that read data from the lake. Dataflows that load data to an Azure Data Lake Storage account store data in Common Data Model folders. Common Data Model folders contain schematized data and metadata in a standardized format, to facilitate data exchange and to enable full interoperability across services that produce or consume data stored in an organization’s Azure Data Lake Storage account as the shared storage layer.
Advanced Analytics and AI with Azure: Power Platform dataflows store data in Dataverse or Azure Data Lake Storage—which means that data ingested through dataflows is now available to data engineers and data scientists to leverage the full power of Azure Data Services, such as Azure Machine Learning, Azure Databricks, and Azure SQL Data Warehouse for advanced analytics and AI. This enables business analysts, data engineers, and data scientists to collaborate on the same data within their organization.
Support for Common Data Model: Common Data Model is a set of a standardized data schemas and a metadata system to allow consistency of data and its meaning across applications and business processes. Dataflows support Common Data Model by offering easy mapping from any data in any shape into the standard Common Data Model entities, such as Account and Contact. Dataflows also land the data, both standard and custom entities, in schematized Common Data Model form. Business analysts can take advantage of the standard schema and its semantic consistency, or customize their entities based on their unique needs. Common Data Model continues to evolve as part of the Open Data Initiative.
Dataflow capabilities in Microsoft Power Platform services
Most dataflow capabilities are available in both Power Apps and Power BI. Dataflows are available as part of these services' plans. Some dataflow features are either product-specific or available in different product plans. The following table describes dataflow features and their availability.
|Dataflow capability||Power Apps||Power BI|
|Scheduled refresh||Up to 48 per day||Up to 48 per day|
|Maximum per entity refresh time||Up to 2 hours||Up to 2 hours|
|Dataflow authoring with Power Query Online||Yes||Yes|
|Dataflow management||In Power Apps admin portal||In Power BI admin portal|
|Standardized schema / built-in support for the Common Data Model||Yes||Yes|
|Dataflows Data Connector in Power BI Desktop||For dataflows with Azure Data Lake Storage as the destination||Yes|
|Integration with the organization's Azure Data Lake Storage||Yes||Yes|
|Integration with Dataverse||Yes||No|
|Dataflow linked entities||For dataflows with Azure Data Lake Storage as the destination||Yes|
|Computed Entities (in-storage transformations using M)||For dataflows with Azure Data Lake Storage as the destination||Power BI Premium only|
|Dataflow incremental refresh||For dataflows with Azure Data Lake Storage as the destination, requires Power Apps Plan2||Power BI Premium only|
|Running on Power BI Premium capacity / parallel execution of transforms||No||Yes|
More information about dataflows in Power Apps:
More information about dataflows in Power BI:
The following articles go into more detail about common usage scenarios for dataflows.
For more information about Common Data Model and the Common Data Model folder standard, read the following articles:
View all page feedback
Mapping data flows in Azure Data Factory
APPLIES TO: Azure Data Factory Azure Synapse Analytics
What are mapping data flows?
Mapping data flows are visually designed data transformations in Azure Data Factory. Data flows allow data engineers to develop data transformation logic without writing code. The resulting data flows are executed as activities within Azure Data Factory pipelines that use scaled-out Apache Spark clusters. Data flow activities can be operationalized using existing Azure Data Factory scheduling, control, flow, and monitoring capabilities.
Mapping data flows provide an entirely visual experience with no coding required. Your data flows run on ADF-managed execution clusters for scaled-out data processing. Azure Data Factory handles all the code translation, path optimization, and execution of your data flow jobs.
Data flows are created from the factory resources pane like pipelines and datasets. To create a data flow, select the plus sign next to Factory Resources, and then select Data Flow.
This action takes you to the data flow canvas, where you can create your transformation logic. Select Add source to start configuring your source transformation. For more information, see Source transformation.
Authoring data flows
Mapping data flow has a unique authoring canvas designed to make building transformation logic easy. The data flow canvas is separated into three parts: the top bar, the graph, and the configuration panel.
The graph displays the transformation stream. It shows the lineage of source data as it flows into one or more sinks. To add a new source, select Add source. To add a new transformation, select the plus sign on the lower right of an existing transformation. Learn more on how to manage the data flow graph.
The configuration panel shows the settings specific to the currently selected transformation. If no transformation is selected, it shows the data flow. In the overall data flow configuration, you can add parameters via the Parameters tab. For more information, see Mapping data flow parameters.
Each transformation contains at least four configuration tabs.
The first tab in each transformation's configuration pane contains the settings specific to that transformation. For more information, see that transformation's documentation page.
The Optimize tab contains settings to configure partitioning schemes. To learn more about how to optimize your data flows, see the mapping data flow performance guide.
The Inspect tab provides a view into the metadata of the data stream that you're transforming. You can see column counts, the columns changed, the columns added, data types, the column order, and column references. Inspect is a read-only view of your metadata. You don't need to have debug mode enabled to see metadata in the Inspect pane.
As you change the shape of your data through transformations, you'll see the metadata changes flow in the Inspect pane. If there isn't a defined schema in your source transformation, then metadata won't be visible in the Inspect pane. Lack of metadata is common in schema drift scenarios.
If debug mode is on, the Data Preview tab gives you an interactive snapshot of the data at each transform. For more information, see Data preview in debug mode.
The top bar contains actions that affect the whole data flow, like saving and validation. You can view the underlying JSON code and data flow script of your transformation logic as well. For more information, learn about the data flow script.
View the mapping data flow transformation overview to get a list of available transformations.
Data flow data types
- decimal (includes precision)
Data flow activity
Mapping data flows are operationalized within ADF pipelines using the data flow activity. All a user has to do is specify which integration runtime to use and pass in parameter values. For more information, learn about the Azure integration runtime.
Debug mode allows you to interactively see the results of each transformation step while you build and debug your data flows. The debug session can be used both in when building your data flow logic and running pipeline debug runs with data flow activities. To learn more, see the debug mode documentation.
Monitoring data flows
Mapping data flow integrates with existing Azure Data Factory monitoring capabilities. To learn how to understand data flow monitoring output, see monitoring mapping data flows.
The Azure Data Factory team has created a performance tuning guide to help you optimize the execution time of your data flows after building your business logic.
Mapping data flows are available in the following regions in ADF:
|Azure region||Data flows in ADF|
|Australia Central 2|
|China East 2|
|China North 2||✓|
|East US 2||✓|
|Germany Central (Sovereign)|
|Germany Non-Regional (Sovereign)|
|Germany North (Public)|
|Germany Northeast (Sovereign)|
|Germany West Central (Public)|
|North Central US||✓|
|South Africa North||✓|
|South Africa West|
|South Central US|
|US DoD Central|
|US DoD East|
|US Gov Arizona||✓|
|US Gov Non-Regional|
|US Gov Texas|
|US Gov Virginia||✓|
|West Central US|
|West US 2||✓|
Understanding the differences between dataflow types
Dataflows are used to extract, transform, and load data to a storage destination where it can be leveraged for different scenarios. Because not all storage destinations share the same characteristics, some dataflow features and behaviors differ depending on the storage destination the dataflow loads data into. Before you create a dataflow, it's important to understand how the data is going to be used, and choose the storage destination according to the requirements of your solution.
Selecting a storage destination of a dataflow determines the dataflow's type. A dataflow that loads data into Dataverse tables is categorized as a standard dataflow. Dataflows that load data to analytical entities is categorized as an analytical dataflow.
Dataflows created in Power BI are always analytical dataflows. Dataflows created in Power Apps can either be standard or analytical, depending on your selection when creating the dataflow.
A standard dataflow loads data to Dataverse tables. Standard dataflows can only be created in Power Apps. One benefit of creating this type of dataflow is that any application that depends on data in Dataverse can work with the data created by standard dataflows. Typical applications that leverage Dataverse tables are Power Apps, Power Automate, AI Builder and Power Virtual Agents.
Standard dataflows versions
We've been working on significant updates to standard dataflows to improve their performance and reliability. These improvements will eventually be available to all standard dataflows. But in the interim, we'll differentiate between existing standard dataflows (version 1) and new standard dataflows (version 2) by adding a version indicator in Power Apps.
Standard dataflow versions feature comparison
The following table lists the major features differences between standard dataflows V1 and V2, and provides information about each feature's behavior in each version.
|Feature||Standard V1||Standard V2|
|Maximum number of dataflows that can be saved with automatic schedule per customer tenant||50||Unlimited|
|Maximum number of records ingested per query/table||500,000||Unbounded. The maximum number of records that can be ingested per query or table now depends on Dataverse service protection limits at the time of ingestion.|
|Ingestion speed into Dataverse||Baseline performance||Improved performance by a few factors. Actual results may vary and depend on characteristics of the data ingested, and load on Dataverse service at the time of ingestion.|
|Incremental Refresh policy||Not supported||Supported|
|Resiliency||When Dataverse service protection limits are encountered, a record will be retried up to 3 times.||When Dataverse service protection limits are encountered, a record will be retried up to 3 times.|
An analytical dataflow loads data to storage types optimized for analytics—Azure Data Lake Storage. Microsoft Power Platform environments and Power BI workspaces provide customers with a managed analytical storage location that's bundled with those product licenses. In addition, customers can link their organization’s Azure Data Lake storage account as a destination for dataflows.
Analytical dataflows are capable additional analytical features. For example, integration with Power BI’s AI features or use of computed entities which will be discussed later.
You can create analytical dataflows in Power BI. By default, they'll load data to Power BI’s managed storage. But you can also configure Power BI to store the data in the organization’s Azure Data Lake Storage.
You can also create analytical dataflows in Power Apps and Dynamics 365 customer insights portals. When you're creating a dataflow in Power Apps portal, you can choose between Dataverse manages analytical storage or in your organization’s Azure Data Lake Storage account.
Sometimes, depending on the requirement, you might need to apply some AI and machine learning functions on the data through the dataflow. These functionalities are available in Power BI dataflows and require a Premium workspace.
The following articles discuss how to use AI functions in a dataflow:
Note that the features listed above are Power BI specific and are not available when creating a dataflow in the Power Apps or Dynamics 365 customer insights portals.
One of the reasons to use a computed entity is the ability to process large amounts of data. The computed entity helps in those scenarios. If you have an entity in a dataflow, and another entity in the same dataflow uses the first entity's output, this will create a computed entity.
The computed entity helps with the performance of the data transformations. Instead of re-doing the transformations needed in the first entity multiple times, the transformation will be done only once in the computed entity. Then the result will be used multiple times in other entities.
To learn more about computed entities, see Using computed entities on Power BI Premium.
Computed entities are available only in an analytical dataflow.
Standard vs. analytical dataflows
The following table lists some differences between a standard entity and an analytical entity.
|How to create||Power Platform dataflows||Power BI dataflows|
Power Platform dataflows by selecting the Analytical Entity checkbox when creating the dataflow
|Storage options||Dataverse||Azure Data Lake Storage internal for the Power BI dataflows|
Azure Data Lake Storage external attached to the Power BI or Power Platform dataflows
|Power Query transformations||Yes||Yes|
|Can be used in other applications||Yes, through Dataverse||Power BI dataflows: Only in Power BI|
Power Platform dataflows or Power BI external dataflows: Yes, through Azure Data Lake Storage
|Mapping to standard Entity||Yes||Yes|
|Incremental load||Default incremental-load|
Possible to change using the Delete rows that no longer exist in the query output checkbox at the load settings
|Default full-load |
Possible to set up incremental refresh by setting up the incremental refresh in the dataflow settings
|Scheduled Refresh||Yes||Yes, the possibility of notifying the dataflow owners upon the failure|
Scenarios to use each dataflow type
Here are some sample scenarios and best practice recommendations for each type of dataflow.
Cross-platform usage—standard dataflow
If your plan for building dataflows is to use stored data in multiple platforms (not only Power BI, but also other Microsoft Power Platform services, Dynamics 365, and so on), a standard dataflow is a great choice. Standard dataflows store the data in Dataverse, which you can access through many other platforms and services.
Heavy data transformations on large data tables—analytical dataflow
Analytical dataflows are an excellent option for processing large amounts of data. Analytical dataflows also enhance the computing power behind the transformation. Having the data stored in Azure Data Lake Storage increases the writing speed to a destination. Compared to Dataverse (which might have many rules to check at the time of data storage), Azure Data Lake Storage is faster for read/write transactions on a large amount of data.
AI features—analytical dataflow
If you're planning to use any AI functionality through the data transformation stage, you'll find it helpful to use an analytical dataflow because you can use all the supported AI features with this type of dataflow.
Data flow microsoft
Introducing: Power BI data prep with dataflows
In the modern BI world, data preparation is considered the most difficult, expensive, and time-consuming task, estimated by experts as taking 60%-80% of the time and cost of a typical analytics project. Some of the challenges in those projects include fragmented and incomplete data, complex system integration, business data without any structural consistency, and of course, a high skillset barrier. Specialized expertise, typically reserved for data warehousing professionals, is often required. Such advanced skills are rare and expensive.
To answer many of these challenges, Power BI serves analysts today with industry leading data preparation capabilities using Power Query in Power BI Desktop. Now, With Power BI dataflows, we’re bringing these self-service data preparation capabilities into the Power BI online service, and significantly expanding the capabilities in the following ways:
- Self-service data prep for big data in Power BI – Dataflows can be used to easily ingest, cleanse, transform, integrate, enrich, and schematize data from a large array of transactional and observational sources, encompassing all data preparation logic. Previously, ETL logic could only be included within datasets in Power BI, copied over and over between datasets and bound to dataset management settings. With dataflows, ETL logic is elevated to a first-class artifact within Power BI and includes dedicated authoring and management experiences. Business analysts and BI professionals can use dataflows to handle the most complex data preparation challenges and build on each other’s work, thanks to a revolutionary model-driven calculation engine, which takes care of all the transformation and dependency logic—cutting time, cost, and expertise to a fraction of what’s traditionally been required for those tasks. Better yet, analysts can now easily create dataflows using familiar self-service tools, such as the well known Power Query data preparationexperience. Dataflows are created and easily managed in app workspaces, enjoying all the capabilities that the Power BI service has to offer, such as permission management, scheduled refreshes, and more.
- Advanced Analytics and AI with Azure – Power BI dataflows store data in Azure Data Lake Storage Gen2 – which means that data ingested through a Power BI dataflow is now available to data engineers and data scientists to leverage the full power of Azure Data Services such as Azure Machine Learning, Azure Databricks, and Azure SQL Datawarehouse for advanced analytics and AI. This allows business analysts, data engineers, and data scientists to collaborate on the same data within their organization.
- Support for the Common Data Model – The Common Data Model (CDM) is a set of a standardized data schemas and a metadata system to allow consistency of data and its meaning across applications and business processes. Dataflows support the CDM by offering easy mapping from any data in any shape into the standard CDM entities, such as Account, Contact etc. Dataflows also land the data, both standard and custom entities, in schematized CDM form. Business analysts can take advantage of the standard schema and its semantic consistency, or customize their entities based on their unique needs. The Common Data Model continues to evolve as part of the recently announced Open Data Initiative.
Once dataflows are created, users can use Power BI Desktop and the Power BI service to create datasets, reports, dashboards, and apps to drive deep insights into their business.
Sunrise Technologies utilizes Power BI to reason across data from various sources to improve efficiency and drive business growth.
“The ability to utilize PowerQuery via dataflows in the online service is a huge step forward,” said Brad Edwards, Senior Product Manager at Sunrise Technologies. “A single ETL process can now be used across multiple reports, greatly reducing the time required to deliver and maintain solutions.”
Today, we are excited to announce that dataflows are available for public preview. Check out this video by Adam Saxton (Guy in a Cube)for a quick look at dataflows:
For a deeper dive on dataflows you can read our dataflows whitepaper by Amir Netz, and view this more detailed walkthrough video by Matthew Roche.
Now, buckle up and lets get started:
Getting started with self-service data prep
To get started, simply create a new dataflow in your app workspace.
Note: Dataflow capabilities are available for Pro and Premium licenses. To access dataflow premium features, dataflows must first be enabled for the relevant capacity. Learn more
You can use dataflows to ingest data from a large and growing set of supported on-premises and cloud- based data sources, including Dynamics 365 (using the new Common Data Service for Apps connector), Salesforce, SQL Server, Azure SQL Database and Data Warehouse, Excel, SharePoint, and more. Over time, more and more data sources from Power BI’s extensive catalog will be made available for ingestion using dataflows.
Leveraging the familiar Power Query experience, you can shape your entities to your needs.
You can also use the Advanced Editor for defining your queries in M language.
Once you’ve created a dataflow, you can define its refresh frequency by setting a refresh schedule in the dataflow settings—similar to the refresh settings and experience available for datasets today.
Ingesting larger amounts of data with Incremental Refresh
To support the ingestion of large amounts of data, dataflow’s entities can be configured with incremental refresh settings. With just few clicks, you can ensure refresh only updates data that has changed, rather than ingesting a full copy of the source data with every refresh. With incremental refresh configured, refreshes are faster and more reliable, which also reduces resource consumption. Learn more
Once data is ingested, cleansed, shaped and mapped, you might want to enrich some of your data with other data that exists in your lake.
As explained next, this task can be easily and efficiently performed with Linked entities and Computed entities using Power BI Premium.
Building complex ETL projects with Linked entities
Linked entities allow users to reuse data which exists in the lake and manage and organize projects with complex ETL processes, from one or multiple sources, thereby allowing analysts to build on each other’s work.
You can create multiple dataflows with links between them, thus organizing and leveraging them as building blocks in your ETL chain, on your path to achieve business insights.
In addition, Linked entities lets you reuse data without data duplication, improving data consistency and reducing maintenance efforts. Learn more about linked entities.
Let’s look at an example of performing advanced data prep on Dynamics 365 for Sales data and support-call data from the service call center.
A best practice for complex projects is to use a single dataflow for each data source. So in this example, one dataflow ingests and preps Sales data from the CRM system, and another dataflow ingests data from the Services system.
Each dataflow can be scheduled to refresh independently, according to the frequency of the changes in the source system.
Then with Linked entities, a third dataflow can be created to leverage and enrich the existing Sales and Services data.
Gaining further insights with Computed entities
Computed entities let you perform in-storage computations on data that has already been ingested, enabling you to create advanced data transformation pipelines.
A new recalculation engine automatically takes care of all dependency logic within a workspace, and takes care of recomputing all dependent data.
In our example, there’s now a dataflow that contains linked entities to Account data from Dynamics and ServiceCalls data from service call center.
ServiceCalls data is raw data that specified the time and sentiment for each call made to the service center. By performing an aggregation on the service call data, you can get a view of how many calls were done in the last period for each of the accounts you have in the system.
This lets you quickly gain insights for the top accounts regarding their serviceability status.
To do this, you can create a new computed entity that performs in-lake transformations on the data that has already been ingested to the ServiceCalls entity.
To create a new computed entity using service-call data, right click the ServiceCalls entity, and choose Reference from the menu.
You can then perform aggregations like summary, average, and distinct count. To join two tables, you can use a combine tables transformation and
the result of the operation can be a new computed entity that is an enrichment of data from multiple sources.
As mentioned, dataflows have a model-driven calculation engine, which takes care of all the transformation and dependency logic. So in our example, you wouldn’t need to spend time syncing the refresh logic for your linked and computed entities. Learn more about computed entities.
Connecting datasets to your data
Finally, now that you’ve created your dataflows and defined how to keep your data updated, you’re ready to leverage your dataflows to build various datasets with Power BI Desktop.
Learn more about how toConnect to Power BI dataflows in Power BI Desktop. Once your data is connected, your path is clear to generate insights on top of your data using reports, dashboards, and apps.
That’s it, now you’re on the fast track to easily prep your organizational data and accelerate your time to insights.
Stay tuned for more updates as we introduce more and more capabilities – we have much lined up!
What are dataflows?
Dataflows are a self-service, cloud-based, data preparation technology. Dataflows enable customers to ingest, transform, and load data into Microsoft Dataverse environments, Power BI workspaces, or your organization's Azure Data Lake Storage account. Dataflows are authored by using Power Query, a unified data connectivity and preparation experience already featured in many Microsoft products, including Excel and Power BI. Customers can trigger dataflows to run either on demand or automatically on a schedule; data is always kept up to date.
Dataflows can be created in multiple Microsoft products
Dataflows are featured in multiple Microsoft products and don't require a dataflow-specific license to be created or run. Dataflows are available in Power Apps, Power BI, and Dynamics 365 Customer Insights. The ability to create and run dataflows is bundled with those products' licenses. Dataflow features are mostly common across all products they're featured in, but some product-specific features might exist in dataflows created in one product versus another.
How does the dataflow function?
The previous image shows an overall view of how a dataflow is defined. A dataflow gets data from different data sources (more than 80 data sources are supported already). Then, based on the transformations configured with the Power Query authoring experience, the dataflow transforms the data by using the dataflow engine. Finally, the data is loaded to the output destination, which can be a Microsoft Power Platform environment, a Power BI workspace, or the organization's Azure Data Lake Storage account.
Dataflows run in the cloud
Dataflows are cloud-based. When a dataflow is authored and saved, its definition is stored in the cloud. A dataflow also runs in the cloud. However, if a data source is on-premises, an on-premises data gateway can be used to extract the data to the cloud. When a dataflow run is triggered, the data transformation and computation happens in the cloud, and the destination is always in the cloud.
Dataflows use a powerful transformation engine
Power Query is the data transformation engine used in the dataflow. This engine is capable enough to support many advanced transformations. It also uses a straightforward, yet powerful, graphical user interface called Power Query Editor. You can use dataflows with this editor to develop your data integration solutions faster and more easily.
Dataflow integration with Microsoft Power Platform and Dynamics 365
Because a dataflow stores the resulting entities in cloud-based storage, other services can interact with the data produced by dataflows.
For example, Power BI, Power Apps, Power Automate, Power Virtual Agents, and Dynamics 365 applications can get the data produced by the dataflow by connecting to Dataverse, a Power Platform dataflow connector, or directly through the lake, depending on the destination configured at dataflow creation time.
Benefits of dataflows
The following list highlights some of the benefits of using dataflows:
A dataflow decouples the data transformation layer from the modeling and visualization layer in a Power BI solution.
The data transformation code can reside in a central location, a dataflow, rather than be spread out among multiple artifacts.
A dataflow creator only needs Power Query skills. In an environment with multiple creators, the dataflow creator can be part of a team that together builds the entire BI solution or operational application.
A dataflow is product-agnostic. It's not a component of Power BI only; you can get its data in other tools and services.
Dataflows take advantage of Power Query, a powerful, graphical, self-service data transformation experience.
Dataflows run entirely in the cloud. No additional infrastructure is required.
You have multiple options for starting to work with dataflows, using licenses for Power Apps, Power BI, and Customer Insights.
Although dataflows are capable of advanced transformations, they're designed for self-service scenarios and require no IT or developer background.
Use-case scenarios for dataflows
You can use dataflows for many purposes. The following scenarios provide a few examples of common use cases for dataflows.
Data migration from legacy systems
In this scenario, the decision has been made by an organization to use Power Apps for the new user interface experience rather than the legacy on-premises system. Power Apps, Power Automate, and AI Builder all use Dataverse as the primary data storage system. The current data in the existing on-premises system can be migrated into Dataverse by using a dataflow, and then these products can use that data.
Using dataflows to build a data warehouse
You can use dataflows as a replacement for other extract, transform, load (ETL) tools to build a data warehouse. In this scenario, the data engineers of a company decide to use dataflows to build their star schema–designed data warehouse, including fact and dimension tables in Data Lake Storage. Then Power BI is used to generate reports and dashboards by getting data from the dataflows.
Using dataflows to build a dimensional model
You can use dataflows as a replacement for other ETL tools to build a dimensional model. For example, the data engineers of a company decide to use dataflows to build the star-schema designed dimensional model, including fact and dimension tables in Azure Data Lake Storage Gen2. Then Power BI is used to generate reports and dashboards by getting data from the dataflows.
Centralize data preparation and reuse of datasets across multiple Power BI solutions
If multiple Power BI solutions are using the same transformed version of a table, the process to create the table will be repeated multiple times. This increases the load on the source system, consumes more resources, and creates duplicate data with multiple points of failure. Instead, a single dataflow can be created to compute the data for all solutions. Power BI can then reuse the result of the transformation in all solutions. The dataflow, if used in such a way, can be part of a robust Power BI implementation architecture that avoids the Power Query code duplicates and reduces the maintenance costs of the data integration layer.
The following articles provide further study materials for dataflows.
- Kawasaki zx 1100
- Merrill shoe outlet
- Klowdtv customer service
- Versatube carport installation
- Comodo help
- Panorama admin guide
- Altz lee
- Steel partners llc
- Luxury elite cassette
- Ipad wired speakers
Introduction to dataflows and self-service data prep
- 2 minutes to read
As data volume continues to grow, so does the challenge of wrangling that data into well-formed, actionable information. We want data that’s ready for analytics, to populate visuals, reports, and dashboards, so we can quickly turn our volumes of data into actionable insights. With self-service data prep for big data in Power BI, you can go from data to Power BI insights with just a few clicks.
When to use dataflows
Dataflows are designed to support the following scenarios:
Create reusable transformation logic that can be shared by many datasets and reports inside Power BI. Dataflows promote reusability of the underlying data elements, preventing the need to create separate connections with your cloud or on-premise data sources.
Expose the data in your own Azure Data Lake Gen 2 storage, enabling you to connect other Azure services to the raw underlying data.
Create a single source of the truth by forcing analysts to connect to the dataflows, rather than connecting to the underlying systems, providing you with control over which data is accessed, and how data is exposed to report creators. You can also map the data to industry standard definitions, enabling you to create tidy curated views, which can work with other services and products in the Power Platform.
If you want to work with large data volumes and perform ETL at scale, dataflows with Power BI Premium scales more efficiently and gives you more flexibility. Dataflows supports a wide range of cloud and on-premise sources.
Prevent analysts from having direct access to the underlying data source. Since report creators can build on top of dataflows, it may be more convenient for you to allow access to underlying data sources only to a few individuals, and then provide access to the dataflows for analysts to build on top of. This approach reduces the load to the underlying systems, and gives administrators finer control of when the systems get loaded from refreshes.
Once you’ve created a dataflow, you can use Power BI Desktop and the Power BI service to create datasets, reports, dashboards, and apps that leverage the Common Data Model to drive deep insights into your business activities. Dataflow refresh scheduling is managed directly from the workspace in which your dataflow was created, just like your datasets.
This article provided an overview of self-service data prep for big data in Power BI, and the many ways you can use it.
The following articles provide more information about dataflows and Power BI:
For more information about the Common Data Model, you can read its overview article: