Cross-Workspace Metrics in Power BI: Permissions, RLS, and the Real Cost of KPI Aggregation

Light

A Metrics scorecard in Power BI can reference KPIs from separate datasets and workspaces, but the linking mechanics and permission model trip up most devs on the first attempt. By the end of this article, you’ll know exactly how to build a cross-workspace KPI scorecard, surface the real-world gotchas (including refresh lag, workspace access, and the non-obvious impact of dataset-level security), and decide when Metrics is the right tool for your scenario versus a custom report or a dedicated data mart.

Metric Scorecards: What They Actually Aggregate (and Why That Matters)

Metrics (formerly Goals) isn’t just a dashboard that pins visuals from different reports. Under the hood, each metric stores a reference to a specific measure in a specific dataset, with its own filter context and a refresh snapshot. The ability to aggregate metrics from multiple datasets—even across workspaces—seems like a shortcut to a unified KPI view, but the mechanism comes with technical debt:

• Each metric is just a pointer: It doesn’t copy, cache, or transform the underlying data. It evaluates the referenced measure in the source dataset, using the filter context you set when you define the metric.
• Cross-workspace metrics multiply access checks: To add a metric from another workspace, you need at least Build permission on the target dataset; the user viewing the scorecard must also have access to every dataset referenced, not just the scorecard workspace. Workspace membership alone is not sufficient.
• No enforced atomicity: Each metric’s value is only as fresh as the last refresh of its source dataset. There is no synchronization—metrics from different datasets can (and often do) represent different data snapshots.

This design means that while Metrics can surface KPIs from multiple datasets, it can’t guarantee they’re comparable in time, context, or security. That’s the trap: users expect a unified view, but the platform doesn’t enforce one.

Permission and Refresh: The Hidden Drag on Cross-Workspace Metrics

Most first attempts at cross-workspace scorecards fail for reasons that aren’t obvious in the UI:

• Metric visibility = minimum common permissions: If a user lacks Read (or Build) access to any referenced dataset, the corresponding metric fails to load—regardless of their scorecard workspace role. The error is per-metric, not per-scorecard, so partial failures are common.
• Refresh timing is never aligned by default: Metric values are evaluated as-of the last refresh of their source datasets. There’s no guarantee (and no warning) that all metrics represent the same time period. If Dim_Date is out of sync or the refresh cadence differs, time-based comparisons are misleading by default.
• RLS is honored, but not harmonized: Each metric is filtered by the viewer’s effective permissions in its source dataset. If you use dynamic RLS (USERPRINCIPALNAME()), the same user may see different slices of data for each metric, depending on how RLS is configured—and there’s no UI indication of mismatched filters.

The upshot: cross-workspace metrics surface permission and refresh mismatches directly to end users. If you’re aggregating more than two datasets, expect to spend more time troubleshooting access, RLS, and “inconsistent” numbers than building the scorecard itself.

Worked Example: Cross-Workspace Scorecard with RLS and Refresh Pitfalls

Construct a scenario: two sales teams, each with their own workspace—“Sales_North” and “Sales_South”—and their own dataset. Both datasets define a [Total Sales] measure and a marked Dim_Date table. The business wants a single scorecard (“All Regions KPIs”) in a new “Executive KPIs” workspace, aggregating both teams’ sales and a combined goal.

1. Create the Metrics scorecard in “Executive KPIs”.
2. Add a metric “Sales North Total” referencing [Total Sales] from Sales_North (requires Build on Sales_North dataset).
3. Add a metric “Sales South Total” referencing [Total Sales] from Sales_South (same permissions).
4. Add a manual goal (“Combined Sales Goal”) as a static value.

Test with a user who has only Viewer access on “Executive KPIs”. They’ll see errors for both metrics—unless they also have at least Read access to both underlying datasets. Granting Viewer on the datasets isn’t enough; they need explicit dataset permissions. If either dataset is mid-refresh, the scorecard can show one metric as “new” and another as “old”, with no warning or synchronization.

Add RLS to both datasets, filtering by region via:

// In Sales_North: RLS filter on 'Dim_Region'
[Region] = LOOKUPVALUE('UserRegion'[Region], 'UserRegion'[UPN], USERPRINCIPALNAME())

Suppose the executive is mapped to “All” in one dataset and “North” only in the other. The scorecard will show “Sales North Total” and “Sales South Total” filtered by different RLS logic—no error, no warning, just quietly mismatched numbers. Unless you test with specific user mappings, this edge case is easy to miss and difficult to explain after the fact.

How to Actually Aggregate KPIs Across Workspaces: A Realistic Path

Metrics works for surface-level KPI assembly, but the minute you need atomic cross-dataset calculations, harmonized RLS, or truly synchronized refresh, you hit its limits. Here’s how I approach the problem when Metrics isn’t enough:

• Build a thin, aggregated dataset: Use Power Query to connect to the underlying datasets (using shared dimensions like Date and Region), and model the combined KPIs directly. This approach centralizes RLS and ensures all measures are calculated on the same data snapshot.
• Architect for cross-workspace sources: If your datasets live in different workspaces, use shared storage (e.g., Fabric OneLake, or shared dataflows) to stage the required tables, then build your aggregated dataset in a neutral workspace. Document which tables are “authoritative” to avoid drift.
• Coordinate refreshes: Set the aggregated dataset to refresh after all source datasets/dataflows complete, using refresh dependencies or external orchestration. This minimizes data skew and ensures the scorecard is always “as of” a known point in time.
• Flatten RLS logic: Apply a single, explicit RLS pattern in the aggregated dataset. If you must combine user-region mappings, union or intersect the user access tables to guarantee consistency across all KPIs.

This pattern takes more up-front work, but it eliminates the silent failure modes of Metrics: partial permissions, RLS mismatch, and out-of-sync data. The trade-off is model complexity—if your KPIs are genuinely independent and minor inconsistencies are acceptable, Metrics may still be faster to deploy.

Checklist: Building Cross-Workspace Metrics Without Shooting Yourself in the Foot

• Every viewer must have at least Read (preferably Build) access to all source datasets, not just the scorecard workspace.
• Test RLS in each dataset using a least-permission test account. Confirm that each metric reflects the correct filter context for every user type.
• Document refresh cadence for each dataset. Communicate to business users that metrics may reflect data from different points in time.
• For KPIs requiring cross-dataset logic or atomicity, build an aggregated dataset with unified dimensions and RLS.
• Use Metrics only where the business can tolerate some inconsistency and the underlying measures already exist as intended.

Metrics (Goals) provides a fast way to assemble KPIs from different workspaces, but the price is hidden in permission sprawl, refresh inconsistency, and RLS edge cases. Before you commit to a cross-workspace scorecard, map out access, refresh, and security for every source—and plan for aggregated datasets if your requirements go beyond “just display these numbers”.