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

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.