Implementing Power BI Dataflow Linked and Computed Entities to Centralize Reusable Transformation Logic Across Enterprise Workspaces

Introduction

Picture this: your organization has fifteen Power BI workspaces spread across finance, operations, HR, and sales. Every one of those teams has a report that uses customer data. And every one of those teams has built their own version of the customer transformation logic — their own way of cleaning addresses, standardizing region codes, and calculating customer lifetime value. When the source system changes a column name, you get fifteen support tickets. When someone discovers a bug in the region mapping, you fix it in one workspace and forget the other fourteen. This is the data transformation equivalent of a distributed monolith — all the complexity, none of the benefits.

Linked and computed entities in Power BI Dataflows exist precisely to solve this problem. They let you define transformation logic once in a central dataflow and then reference or extend that logic from any other dataflow across your enterprise, without copying a single line of M code. By the end of this lesson, you'll understand how these two mechanisms work, when to use each, and how to wire them together into a coherent multi-tier transformation architecture.

What you'll learn:

• The difference between a standard entity, a linked entity, and a computed entity — and why the distinction matters
• How to create a central "foundation" dataflow and expose its entities for reuse
• How to link to an existing entity from a different workspace's dataflow
• How to build computed entities that apply additional transformations on top of linked entities
• How to structure a two-tier (or three-tier) dataflow architecture that scales across dozens of workspaces
• Common mistakes that cause circular dependencies, refresh failures, and performance bottlenecks

---

Prerequisites

Before working through this lesson, you should be comfortable with the basics of Power BI Dataflows — creating a dataflow, writing M queries in Power Query Online, and understanding what an entity is. If you need a refresher, start with Power BI Dataflows: Centralized ETL for the Enterprise before continuing here.

You'll also need:

• A Power BI Premium, Premium Per User (PPU), or Fabric capacity — linked and computed entities require Enhanced Compute Engine support
• At least two workspaces assigned to a Premium or PPU capacity
• Contributor or higher permissions in both workspaces

---

Understanding the Three Entity Types

Before you touch any UI, you need a clear mental model of the three entity types you'll be working with. Conflating them is the most common source of confusion for people new to this topic.

Standard entities are what you get when you create a regular dataflow. You connect to a source, apply Power Query transformations, and the result gets stored in Azure Data Lake Storage Gen2 as a set of Parquet files. Every refresh pulls from the source and re-runs the transformation logic.

Linked entities are references to a standard entity that already exists in another dataflow. When you create a linked entity, you're not copying the data or the transformation code. You're pointing at the already-materialized output of another dataflow. The linked entity is read-only — you cannot change its schema or add steps. Refreshes are read-through: the consuming dataflow reads the data that was written during the source dataflow's last refresh.

Computed entities are where the real power lies. A computed entity is a transformation applied to a linked entity (or another computed entity). Because the input is already materialized in the lake, the computation happens entirely within the Enhanced Compute Engine — not against the original source system. This is faster, cheaper, and it keeps your source systems from being hammered by every downstream consumer.

Think of it this way: if a standard entity is like a recipe that reads raw ingredients from the pantry, then a linked entity is a reference to the finished dish, and a computed entity is what happens when you take that dish and add your own seasoning before serving it to your specific guests.

---

Why This Architecture Matters at Enterprise Scale

The core value proposition here is the elimination of redundant source queries and divergent transformation logic. Let's make this concrete.

Imagine a retail organization where the Customer table lives in a Dynamics 365 instance. Without linked and computed entities, every team that needs customer data would build their own dataflow connecting directly to Dynamics 365. That means:

• Every refresh hits the Dynamics 365 API multiple times
• Each team applies slightly different cleaning logic, creating "customer" definitions that don't quite match
• When the Dynamics API changes, all fifteen dataflows break simultaneously

With linked and computed entities, you build one central Customer entity with the authoritative cleaning and standardization logic. Every downstream team links to it. The Dynamics 365 API gets hit once per refresh cycle. Teams can add their own computed transformations on top — the finance team might filter to customers with active billing accounts, while the marketing team adds a computed column for email engagement score — but the foundational data is always consistent.

This connects directly to the idea of a governed enterprise data layer. If you're building out a proper semantic layer, you'll find this pattern described further in Implementing Power BI Dataset Sharing and Cross-Workspace Live Connections to Build a Reusable Enterprise Semantic Layer.

---

Building the Foundation Dataflow

Let's walk through a realistic scenario. You're the data platform team at a mid-sized retailer. You'll build a foundation dataflow in a shared "Core Data" workspace, containing cleaned and standardized versions of your Customer, Product, and SalesTransaction entities. Department teams will link to these.

Step 1: Create the Core Data Workspace and Dataflow

In the Power BI Service, navigate to your workspaces list. Create a new workspace called "Core Data — Foundation" and assign it to your Premium capacity. This workspace will own the authoritative transformation logic.

Inside that workspace, click New → Dataflow. Choose "Define new tables" (in some UI versions this appears as "Add new tables" or the standard Power Query Online experience). Name this dataflow Foundation — Core Entities.

Step 2: Connect to Your Source and Build Standard Entities

Let's build the Customer entity. In Power Query Online, add a new query connecting to your SQL Server source (or whatever CRM system holds customer data). Apply your full transformation pipeline:

let
    Source = Sql.Database("crm-prod.database.windows.net", "CRMData"),
    CustomerTable = Source{[Schema="dbo", Item="Customers"]}[Data],
    
    // Remove test and internal accounts
    FilteredRows = Table.SelectRows(CustomerTable, each 
        [AccountType] <> "Internal" and [IsTestAccount] = false),
    
    // Standardize region codes to ISO 3166-2
    AddRegionCode = Table.AddColumn(FilteredRows, "RegionCode", each
        if [State] = "California" then "US-CA"
        else if [State] = "New York" then "US-NY"
        else if [State] = "Texas" then "US-TX"
        else "US-OTHER"),
    
    // Clean phone numbers to E.164 format
    CleanPhone = Table.TransformColumns(AddRegionCode, {
        {"Phone", each Text.Trim(Text.Replace(Text.Replace(_, "-", ""), " ", "")), type text}
    }),
    
    // Enforce consistent column types
    TypedTable = Table.TransformColumnTypes(CleanPhone, {
        {"CustomerID", Int64.Type},
        {"Email", type text},
        {"CreatedDate", type date},
        {"RegionCode", type text},
        {"Phone", type text}
    })
in
    TypedTable

Name this query Customer. Repeat this process for Product and SalesTransaction, applying whatever cleaning logic your organization requires. Then save and publish the dataflow.

Step 3: Run the Initial Refresh

Before any linked entity can read data, the foundation dataflow must complete at least one successful refresh. The data needs to be physically written to the lake. Navigate to the dataflow in your workspace, click the refresh icon, and wait for it to complete. Once you see a green checkmark and a "Last refreshed" timestamp, the foundation layer is ready.

---

Creating Linked Entities in Downstream Dataflows

Now you'll move to the Finance team's workspace, which needs the Customer data but wants to add some finance-specific columns.

Step 1: Create a New Dataflow in the Finance Workspace

Navigate to the Finance workspace (also on Premium capacity). Create a new dataflow called Finance — Customer Analytics. In the Power Query Online editor, instead of connecting to a data source, click Get data → Power Platform → Dataflows.

This opens the dataflow connector, which shows you the dataflows available across your organization's workspaces. Find "Foundation — Core Entities" in the "Core Data — Foundation" workspace. Expand it and you'll see the Customer, Product, and SalesTransaction entities listed individually. Select Customer and click Next.

Power BI will create a linked entity in your dataflow. The query will look something like this in the advanced editor:

let
    Source = PowerPlatform.Dataflows(null),
    Workspace = Source{[workspaceId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"]}[Data],
    Dataflows = Workspace{[dataflowId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"]}[Data],
    Entity = Dataflows{[entity = "Customer", version = ""]}[Data]
in
    Entity

---

Building Computed Entities on Top of Linked Entities

Here's where the architecture becomes genuinely powerful. The Finance team needs to:

1. Filter customers to those with an active billing status
2. Add a computed column for the customer's assigned credit tier
3. Join customer data with SalesTransaction data to pre-aggregate lifetime revenue

Each of these becomes its own computed entity.

Step 1: Enable the Enhanced Compute Engine

Before you can create computed entities, make sure the Enhanced Compute Engine is enabled for your capacity. In the Power BI Admin portal, navigate to Capacity Settings → your capacity → Dataflows → Enhanced Compute Engine Settings → set to On. Without this, Power BI will silently fall back to processing in Power Query Online, which defeats the purpose.

Step 2: Create the First Computed Entity

In your Finance dataflow, add a new blank query (not a data source connection — just a new empty query). Open the Advanced Editor and write:

let
    // Reference the linked Customer entity
    LinkedCustomer = Customer,
    
    // Filter to active billing accounts only
    ActiveCustomers = Table.SelectRows(LinkedCustomer, each 
        [BillingStatus] = "Active"),
    
    // Add credit tier based on business rules
    WithCreditTier = Table.AddColumn(ActiveCustomers, "CreditTier", each
        if [AnnualRevenue] >= 1000000 then "Platinum"
        else if [AnnualRevenue] >= 250000 then "Gold"
        else if [AnnualRevenue] >= 50000 then "Silver"
        else "Standard",
        type text),
    
    // Add a flag for enterprise accounts
    WithEnterpriseFlag = Table.AddColumn(WithCreditTier, "IsEnterpriseAccount", each
        [CreditTier] = "Platinum" or [CreditTier] = "Gold",
        type logical)
in
    WithEnterpriseFlag

Name this query Finance_Customer. Right-click the query in the query list and confirm that it shows a lightning bolt icon — that icon indicates Power BI has recognized it as a computed entity that will run against the Enhanced Compute Engine.

Step 3: Build the Revenue Aggregation Computed Entity

Now link the SalesTransaction entity from the foundation dataflow into this Finance dataflow, following the same process as before. Then create a second computed entity that joins and aggregates:

let
    Customers = Finance_Customer,
    Transactions = SalesTransaction,
    
    // Aggregate transactions to customer level
    AggregatedRevenue = Table.Group(
        Transactions,
        {"CustomerID"},
        {
            {"TotalRevenue", each List.Sum([SaleAmount]), type number},
            {"TransactionCount", each Table.RowCount(_), Int64.Type},
            {"LastPurchaseDate", each List.Max([TransactionDate]), type date}
        }
    ),
    
    // Join back to the customer entity
    CustomerWithRevenue = Table.NestedJoin(
        Customers,
        {"CustomerID"},
        AggregatedRevenue,
        {"CustomerID"},
        "RevenueData",
        JoinKind.Left
    ),
    
    // Expand the joined columns
    Expanded = Table.ExpandTableColumn(
        CustomerWithRevenue,
        "RevenueData",
        {"TotalRevenue", "TransactionCount", "LastPurchaseDate"},
        {"TotalRevenue", "TransactionCount", "LastPurchaseDate"}
    )
in
    Expanded

Name this Finance_CustomerLifetimeValue. Save and publish the Finance dataflow.

---

Understanding Refresh Ordering and Dependencies

This is the area where most enterprise implementations hit trouble. There's a strict dependency chain here:

1. Foundation dataflow must refresh first (writes Customer, Product, SalesTransaction to the lake)
2. The Finance dataflow reads from the already-written data, applies computed transformations, and writes Finance_Customer and Finance_CustomerLifetimeValue to the lake
3. Power BI datasets in the Finance workspace connect to Finance_CustomerLifetimeValue

If the Finance dataflow tries to refresh before the Foundation dataflow has completed, it will read stale data. If you're using Power BI deployment pipelines to promote content across environments, the linked entity references must resolve correctly in each stage — GUIDs for workspace and dataflow IDs will differ between dev, test, and prod, which requires careful parameterization.

---

Governance and Lineage Considerations

When you build a multi-tier dataflow architecture, governance becomes critical. Who owns the Foundation dataflow? Who can modify it? How do you communicate breaking changes to downstream teams?

The workspace structure itself enforces some of this. Only members of the "Core Data — Foundation" workspace can modify the foundation dataflow. Downstream teams get read-only access to link to its entities. This natural boundary is valuable, and you should make it explicit in your organization's data governance documentation.

For lineage tracking, the Power BI Service's built-in lineage view (available from any workspace's lineage button) will show you the full chain: source system → foundation dataflow entity → linked entity → computed entity → dataset → report. This makes impact analysis straightforward when a source system change is coming. Lineage and impact analysis are covered in depth in Implementing Power BI Workspace-Level Lineage and Impact Analysis to Manage Dataset Dependencies Across the Enterprise.

If you're operating in a regulated environment, you'll also want to apply sensitivity labels to your foundation dataflow entities so that classification propagates downstream automatically. That topic is addressed in Implementing Power BI Tenant Settings and Sensitivity Labels for Enterprise Data Protection and Compliance.

---

Hands-On Exercise

Work through this end-to-end exercise in your own Power BI environment.

Scenario: You're building a foundation data layer for a fictional retail company. You have two workspaces on PPU capacity: "Platform — Foundation" and "Marketing — Analytics."

Exercise steps:

1. In "Platform — Foundation," create a dataflow called Retail Core Entities. Add a Product entity that connects to any available data source (you can use a manually entered table in Power Query Online — click Enter Data and create a table with columns: ProductID, ProductName, Category, UnitCost, UnitPrice). Add five or more rows of realistic product data. Apply a computed margin column: Margin = UnitPrice - UnitCost. Publish and refresh the dataflow.

2. In "Marketing — Analytics," create a dataflow called Marketing Product Analysis. Use the Dataflows connector to link to the Product entity from Retail Core Entities.

3. In the same Marketing dataflow, create a computed entity called Marketing_Product that references the linked Product entity and adds two new columns: MarginPct (calculated as Margin / UnitPrice) and PriceTier (a conditional column: "Premium" if UnitPrice > 100, "Mid-Range" if UnitPrice > 40, otherwise "Economy").

4. Publish and refresh the Marketing dataflow. Verify that the computed entity reflects the data from the foundation layer.

5. Go back to the "Platform — Foundation" workspace and edit the Product entity — add a new row or change a value. Refresh the foundation dataflow, then refresh the Marketing dataflow. Confirm that the change propagates through without any changes to the Marketing dataflow's M code.

Success criteria: The Marketing_Product computed entity contains the margin percentage and price tier columns, reflects changes made in the foundation layer after a refresh cycle, and shows a lightning bolt icon indicating computed entity status.

---

Common Mistakes & Troubleshooting

"My query doesn't show the lightning bolt icon." This means Power BI hasn't classified your query as a computed entity. Check that: (1) the Enhanced Compute Engine is enabled on your capacity, (2) your query references only entities within the same dataflow (not external sources), and (3) you haven't accidentally broken the reference by renaming the source entity.

"The linked entity shows data from yesterday even after the foundation dataflow refreshed." Linked entities read from the materialized snapshot written during the last refresh. If you refreshed the foundation dataflow but the downstream dataflow didn't re-run, you're reading the previous snapshot. Trigger a refresh of the downstream dataflow explicitly, or configure proper refresh scheduling.

"I'm getting a circular dependency error." This happens when Entity A references Entity B, and Entity B (directly or indirectly) references Entity A. Power BI cannot resolve this. Map your entity dependencies on paper before building — the flow must always be directional, with no cycles.

"The dataflow connector doesn't show the other workspace's dataflow." You need at least Viewer permissions in the source workspace, and the source dataflow must have been published (not just saved as a draft). Also confirm both workspaces are on Premium or PPU capacity — linked entities between non-Premium workspaces are not supported.

"Refresh is slow even after enabling the Enhanced Compute Engine." Confirm that your computed entities are actually using the engine (lightning bolt icon present). Also check whether you're doing large joins across multiple linked entities — these can be expensive. Consider whether incremental refresh on the foundation dataflow entities would reduce the data volume being processed downstream.

---

Summary & Next Steps

You've now covered the complete picture of linked and computed entities: what they are, why the distinction matters, how to build a foundation layer that teams across your enterprise can reuse, and how to add team-specific transformations without touching the authoritative source logic. The key architectural principles to carry forward are:

• One source of truth: transformation logic lives in the foundation dataflow, not in fifteen department workflows
• Computed entities for extension: linked entities are read-only references; computed entities are where you add business-unit-specific logic
• Dependency ordering: always refresh foundation before dependent dataflows, and use the Enhanced Compute Engine for performance
• Governance by workspace boundary: workspace permissions naturally enforce who can change foundational logic

From here, there are several natural directions to explore. As your dataflow architecture grows, you'll want to think about how datasets connect to these dataflows and how you can share those datasets across workspaces — the reusable enterprise semantic layer approach complements what you've built here. You'll also want to consider how master data management with shared dimensions integrates with a foundation dataflow strategy to ensure that entities like Customer and Product mean the same thing across every report in your organization.