Bizarre Permission Issue: Visuals blank for App Viewers unless granted "Write" access (Import Model)
Hey everyone, I’m running into a wall with a bizarre permission issue in the Power BI Service and could use some architecture-level insights.
The Setup:
- A single semantic model (100% Import) sitting in a workspace.
- Multiple thin reports connected to this single model.
- These reports are bundled into a Power BI App for consumers.
The Problem: Workspace Admins can see everything perfectly. However, App consumers (Viewers) are getting completely blank visuals or zeros on some of the reports. They aren’t getting the gray "X" (Cannot load visual) error—the DAX is successfully evaluating, but it’s returning an empty table context.
The Twist (and what makes no sense): If I go to the dataset permissions and explicitly grant the test Viewer Read, Write, and Build access, the visuals instantly populate. If I strip it back to just Read and Build, the visuals instantly go blank again.
What I have already investigated and ruled out:
- It’s not a Persistent Filter: Having the Viewer click "Reset to default" in the App does nothing.
- It’s not Direct Lake / DirectQuery: The model is 100% Import, so there are no underlying SSO database permission failures.
- No DAX Identity Functions:
USERPRINCIPALNAME()orUSERNAME()are not being used in any of the core measures to spoof security. - Row-Level Security (RLS) is cleared: I found a "ghost" RLS role in the metadata via Tabular Editor that was filtering a
Budget Usertable. I have completely deleted this role from the model and republished. The issue persists. - Object-Level Security (OLS): Checked in Tabular Editor; OLS is set to default/none for the tables involved.
The Final Clue: Even though they share the exact same underlying semantic model, some reports in the App work perfectly for Viewers, while others return blanks.
Since the VertiPaq engine inherently forces anyone with "Write" access to bypass security roles, it feels like the Service is still enforcing a phantom security rule or interpreting a specific relationship/DAX query as an authoring action.
Has anyone seen the Power BI Service enforce a "Write" permission requirement for basic consumers on an Import model? Could a complex bi-directional cross-filter or a specific DAX aggregation pattern (like TREATAS) trigger a Build/Write requirement in the Service?