Forum Discussion
Two reports on one data model
Hi all,
I’m working on designing a clean and scalable Power BI / Microsoft Fabric setup and would appreciate some architectural guidance.
Scenario:
I currently have a report (KPIs All) built on a shared semantic model and published via an app. I now need to introduce a second report (KPIs BA), which should:
- use the same semantic model (single source of truth),
- serve a different audience,
- and enforce stricter data access (RLS).
Questions:
- App & Workspace design
From a best practice / governance perspective:
- Can I expose two separate apps (e.g., KPIs All and KPIs BA) from the same workspace, each targeting different audiences?
- Or is the recommended approach to split this into two workspaces (one per app)?
- RLS behavior with shared semantic model
I understand that RLS is defined at the semantic model level, but I’d like to confirm:
- Is it possible to enforce RLS for one report (KPIs BA), while leaving another report (KPIs All) effectively unrestricted?
- Or is RLS always globally enforced across all reports connected to that semantic model?
Goal:
Ideally, I’d like to avoid duplicating the semantic model while still maintaining:
- clear audience separation,
- secure data access,
- and a maintainable architecture aligned with Fabric best practices.
Any recommendations, patterns (e.g., audiences vs. separate workspaces), or real-world experience would be greatly appreciated.
Thanks in advance!
Power BI currently allows only one app per workspace, so both reports would be included in the same app with audience-level visibility controlling which report each user sees. RLS is enforced at the semantic model level and applies globally to all reports connected to it, meaning you cannot enforce RLS for KPIs BA while leaving KPIs All unrestricted if both connect to the same semantic model. The recommended pattern for your scenario is to keep both reports in the same workspace and use app audiences to control report visibility, then assign the KPIs BA audience users to the appropriate RLS role in the semantic model security settings while leaving KPIs All users unassigned to any role (which bypasses RLS by default for workspace members). If KPIs All users must truly see all data without any RLS evaluation, ensure they have at minimum Member role on the workspace since Admins and Members bypass RLS automatically, while Viewers are subject to RLS.
3 Replies
Hi ALZK , Thank you for reaching out to the Microsoft Community Forum.
In Power BI / Microsoft Fabric, RLS is defined and enforced at the semantic model level, not the report. That means if both KPIs All and KPIs BA connect to the same model, they will always inherit the same RLS rules. There isn’t a way to make one report restricted and another unrestricted off that same model.
You can still separate audiences using apps or audiences within an app, but that only controls access to the reports themselves, it doesn’t change what data users see once they’re in. The data filtering is always driven by the model’s RLS, regardless of which report or app is used.
Given your goal, I suggest you to keep a single source of truth at the data layer, but split the semantic layer into two models: one without RLS (for KPIs All) and one with RLS (for KPIs BA). Both can point to the same Fabric data source, so you avoid duplicating data while keeping security and audience separation clear and predictable.
Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
RLS is welded at the model‑line, so one report can’t be unrestricted while the other is locked. The safe pattern is a tiny model‑dup → RLS only on the BA copy → publish from its own workspace/app.
Power BI currently allows only one app per workspace, so both reports would be included in the same app with audience-level visibility controlling which report each user sees. RLS is enforced at the semantic model level and applies globally to all reports connected to it, meaning you cannot enforce RLS for KPIs BA while leaving KPIs All unrestricted if both connect to the same semantic model. The recommended pattern for your scenario is to keep both reports in the same workspace and use app audiences to control report visibility, then assign the KPIs BA audience users to the appropriate RLS role in the semantic model security settings while leaving KPIs All users unassigned to any role (which bypasses RLS by default for workspace members). If KPIs All users must truly see all data without any RLS evaluation, ensure they have at minimum Member role on the workspace since Admins and Members bypass RLS automatically, while Viewers are subject to RLS.
