One report, one semantic model, per-client visual configuration — is this the right approach?

[robertozsr]

Hi Fabric community,

We are migrating our analytics from Power BI Desktop to Fabric and rethinking our architecture completely.

Current setup Every client has their own semantic model connected to a shared Postgres analytics DB, their own Power BI report published to their own workspace. Works but does not scale.

Target setup One Fabric workspace, one ingestion and transformation pipeline, one semantic model, one report — served to all clients.

What I need to solve

RLS is clear to me for data filtering — each user sees only their rows based on USERPRINCIPALNAME(). That part is fine.

What I am less sure about is the visual layer. Some clients want slightly different KPIs visible, different logos, maybe a page that only applies to them. I want to avoid maintaining N separate reports.

I heard of a config table approach — something like:

client show_kpi_revenue show_kpi_margin show_page_ops

client-a	YES	NO	YES
client-b	YES	YES	NO

Then a DAX measure reads USERPRINCIPALNAME() against this table and drives conditional visibility in the report.

My questions

1. Is this the recommended pattern in Fabric for this use case?
2. How do you handle visual show/hide in practice — blank measure trick, bookmarks, or separate pages per profile/client

Would love to hear from anyone who has built this at scale. Thanks

[robertozsr]

Hello @v-sgandrathi. Great explenation!!!! And useful. Have a great day

[v-sgandrathi]

Hi @robertozsr,

we haven't heard back from you regarding our last response and wanted to check if your issue has been resolved.

Should you have any further questions, feel free to reach out.
Thank you for being a part of the Microsoft Fabric Community Forum!

[robertozsr]

Yes it has been resolved! Thanks

[v-sgandrathi · Accepted solution]

Hi @robertozsr,

Yes, your suggested setup, using a single ingestion pipeline, semantic model, and report with RLS via USERPRINCIPALNAME() is a recommended and scalable approach in Fabric. This centralizes the data model, minimizes duplication, enhances governance, and reduces maintenance compared to managing multiple reports. The main challenge is handling per-client visual customization within one report. Leveraging a configuration or feature flag table with RLS works well for minor variations like showing or hiding certain KPIs, but it should be applied carefully. If client needs vary greatly in layout or user experience, making everything dynamic in one report can lead to complexity and maintenance issues. It's important to find a balanced solution.

In practice, visual show/hide functionality is commonly managed using a combination of a configuration table and DAX measures. This method is the most scalable way to control elements like KPI visibility or minor UI differences by mapping USERPRINCIPALNAME() to a client and returning the actual measure or BLANK() depending on the configuration. However, the “blank measure” technique has its drawbacks, as the visual still takes up space and can create awkward gaps, making it less suitable for full page control or complex layouts. For page-level customization, teams often use bookmarks and buttons to navigate between predefined page states, though this can become challenging to manage with many variations. A more practical solution at scale is to maintain a few duplicate page variants (such as standard, advanced, or operations views) and use configuration logic to direct users to the appropriate version, instead of making a single page dynamic for every client.

Thank you.