A Power BI dashboard cannot be built from scratch without a semantic model, but a semantic model can exist for years without a single dashboard referencing it. If you treat reports, dashboards, and semantic models as interchangeable, you’ll misdiagnose refresh failures, security leaks, and user complaints about “missing” data. By the end of this article, you’ll see why separating these layers is non-negotiable, where the boundary gets fuzzy in practice, and the most common ways practitioners accidentally break the contract between them.
Semantic Models: The Only Layer That Holds Data, Security, and Logic
The semantic model is the only artifact in Power BI that stores data, enforces row-level security (RLS), and defines DAX measures. Reports and dashboards are pure consumers—they don’t hold so much as a byte of your data model. This seems obvious but gets violated in practice whenever someone tries to “secure a report” or “hide a column from a dashboard” and expects the data to be protected.
- Non-obvious failure: Hiding a column in a report or dashboard does not remove access; if the underlying semantic model exposes it, anyone with Build or Analyze permissions can still query it directly (via Analyze in Excel, for example).
- Common confusion: RLS is defined and enforced only at the semantic model level. Reports and dashboards merely pass user context along; they do not add or override RLS.
Here’s a scenario: take a semantic model with a sensitive column, Fact_Sales[UnitCost], and a report that does not show that column in any visual. A user with Build access can still access UnitCost via Analyze in Excel, DAX Studio, or another report. Report- and dashboard-level visual hiding is presentation only.
Worked Example: The RLS Trap with Dashboards
Imagine you have a semantic model with RLS applied to Fact_Sales filtering by Dim_Region[Region]. You pin a report visual to a dashboard. A user with access to the dashboard but not the underlying semantic model will see—nothing. The dashboard tile cannot evaluate any data because it cannot impersonate RLS or retrieve data without permission on the model. This manifests as blank visuals, not as a security breach, but it can look like a bug to end users.
Now invert it: if a user has access to the semantic model but you intended to “hide” certain data in the report, the dashboard is no barrier. They can build their own report and see everything the semantic model exposes, regardless of what the original report or dashboard showed.
Reports: The Only Layer That Defines Visual Interactions and Navigation
Reports are the only artifact where you can define slicers, bookmarks, drillthrough pages, and page navigation. Dashboards flatten these features—no dashboard will preserve a report’s drillthrough, slicers, or dynamic visuals. The dashboard tile is just a static (but periodically refreshed) view, not a live report canvas.
- Non-obvious failure: Pinning a report visual with a slicer applied to a dashboard does not create a slicer on the dashboard. The pinned tile reflects the current filter state at the time of pinning or refresh, but users cannot interactively slice or drill on the dashboard itself.
- Counterintuitive result: Dashboard tiles do not support report-level page filters, drillthrough, or bookmarks. These interactions are lost unless the user clicks through to open the underlying report.
It is common to expect dashboard tiles to “stay linked” to filters or bookmarks, especially when building for self-service users. The only way for users to interact with these features is to open the report itself—dashboards are a read-only, static snapshot.
Worked Example: Why a Dashboard Cannot Replace a Report
Take a report with a slicer on Dim_Date[Year] and a visual showing sales by product. If you pin this visual to a dashboard, the dashboard tile will reflect whatever year was selected when pinned (or at the time of the last data refresh if set to live pin). There is no slicer on the dashboard. If a user clicks the tile, they are taken to the report page, where they can interact with the slicer.
The naive expectation is that a dashboard can serve as a fully interactive report “lite.” In reality, dashboard tiles are snapshots with no user-driven filters or navigation. This is by design, not a missing feature.
Dashboards: Aggregators, Not Modelers—And Why Their Security Is a Mirage
Dashboards aggregate visuals from multiple reports (and models), but they do not own or enforce security, data logic, or model refresh. Their only security boundary is access to the dashboard artifact itself. If a user can see a dashboard tile, they can see whatever data the semantic model exposes for the tile’s query—nothing more, nothing less.
- Gotcha: Granting someone access to a dashboard does not grant access to the underlying semantic model or report unless they already have it. The result: blank tiles or “permission required” errors, not a security hole, but a failed user experience.
- Non-obvious cause: Dashboards do not refresh on model refresh; they refresh on a schedule or when the tile is pinned live. This can decouple dashboard content from the actual underlying data freshness, leading to “stale” visuals even when reports are up-to-date.
From a security and data lineage perspective, the dashboard is the least authoritative artifact. It is a window into the semantic model’s data as filtered by the report visual, not a container of data or logic itself. Any attempt to “restrict access” at the dashboard level is, at best, a presentation filter—not a security boundary.
Worked Example: The Dashboard Sharing Misconception
Suppose you pin visuals from two different reports, each backed by a different semantic model, to a dashboard. You then share the dashboard with a user who has access to only one of the models. The dashboard will show some tiles (from the model they can access), and others will be blank or throw an error. Sharing the dashboard does not grant data access; it simply presents whatever the user is already authorized to see. This fragmented dashboard experience surprises many users, but it is by design—dashboard sharing is never a substitute for model-level access control.
Practical Checklist: Preventing Layer Confusion in Real Projects
- Data and security boundaries live in the semantic model. Never rely on hiding visuals, columns, or pages in reports or dashboards to secure data. Audit permissions at the semantic model, not the report or dashboard.
- Design for interactivity where it belongs. Use reports for filtering, drillthrough, and navigation. Dashboards are for high-level aggregation and quick status, not deep analysis.
- Set user expectations on dashboard interactivity and data freshness. If a dashboard tile is “stale” or missing, check the user’s semantic model permissions and the tile’s refresh schedule.
- Use report-level security sparingly and with full awareness of its limits. RLS and OLS (Object-Level Security) are enforced only at the model layer. Visual-level filters and page hiding are not security boundaries.
When the Boundaries Blur: Field Parameters, Calculation Groups, and the New Layer Confusion
As of recent versions, features like field parameters and calculation groups allow for dynamic visuals and on-the-fly column switching in reports. However, these objects still live in the semantic model, not the report. This means that if you build a report with dynamic field parameters, every consumer of the model (including Analyze in Excel or another Power BI report) can see and use those field parameters, regardless of whether your original report exposes them. The confusion arises when practitioners expect these dynamic features to be “report-only”—they are not.
Conversely, visual calculations (DAX-based, preview feature) are authored at the report layer and are not exposed in the semantic model. They are not available for reuse or external querying. This distinction is new and easy to miss: semantic model artifacts (measures, calculation groups, field parameters) are global to all reports consuming the model; report artifacts (visual calculations, bookmarks, page navigation) are not.
Actionable Takeaway: Enforce the Boundaries, or Prepare for Failure
If you treat the semantic model, report, and dashboard layers as equivalent, you will miss subtle but critical failures—security leaks, data access errors, or “broken” dashboards that are working exactly as designed. The actionable path is to enforce boundaries:
- Audit and secure at the semantic model—never rely on downstream artifacts for security.
- Design for interactivity only in reports; use dashboards for aggregation and alerting, not deep navigation.
- When adopting new features (field parameters, visual calculations), check which layer owns the object and how it propagates to consumers.
- Communicate to users that dashboards are not interactive reports and may show blank tiles if permissions don’t align at the model level.
When you see a report, ask: what semantic model does it reference, and who controls it? When you see a dashboard, ask: who owns the underlying model, and does the viewer have access? Respecting these boundaries is the only way to avoid accidental data exposure, broken user experiences, and missed analytics outcomes.