Forum Discussion
Grant semantic model access to end users
- 1 year ago
Hi NorahTran97
What you’re observing comes down to how Power BI enforces dataset permissions when reports are built on semantic models across workspaces, and why it sometimes feels inconsistent. By design, whenever you share a report that relies on a dataset, the end user must also have at least Read access to that underlying dataset, otherwise the report cannot render. However, there are scenarios where access can be inherited or implicitly granted. For example, if a dataset resides in a workspace backed by Premium capacity and the report is shared through an app or has “Build” permission exposed, some users may be able to view data without you explicitly assigning dataset permissions. This explains why some of your internal users are able to see Dataset1 automatically. Dataset2, on the other hand, likely does not have those same conditions (e.g., no implicit Build permissions, different workspace settings, or stricter security like RLS), so access must be explicitly granted. The inconsistency arises because access behavior depends on a mix of factors: whether the dataset and report live in the same or different workspaces, whether the workspace is Premium, how the report was shared (directly, via app, or link), and whether users already have implicit permissions. In short, your original expectation is correct—best practice is to always grant users Read (and Build, if needed) on any dataset that underpins a shared report to avoid these unpredictable access differences.
Hi NorahTran97
What you’re observing comes down to how Power BI enforces dataset permissions when reports are built on semantic models across workspaces, and why it sometimes feels inconsistent. By design, whenever you share a report that relies on a dataset, the end user must also have at least Read access to that underlying dataset, otherwise the report cannot render. However, there are scenarios where access can be inherited or implicitly granted. For example, if a dataset resides in a workspace backed by Premium capacity and the report is shared through an app or has “Build” permission exposed, some users may be able to view data without you explicitly assigning dataset permissions. This explains why some of your internal users are able to see Dataset1 automatically. Dataset2, on the other hand, likely does not have those same conditions (e.g., no implicit Build permissions, different workspace settings, or stricter security like RLS), so access must be explicitly granted. The inconsistency arises because access behavior depends on a mix of factors: whether the dataset and report live in the same or different workspaces, whether the workspace is Premium, how the report was shared (directly, via app, or link), and whether users already have implicit permissions. In short, your original expectation is correct—best practice is to always grant users Read (and Build, if needed) on any dataset that underpins a shared report to avoid these unpredictable access differences.