Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!Get Fabric certified for FREE! Don't miss your chance! Learn more
Hello everyone,
I have several clients (in the same domain) to which we provide dashboards. While I am realizing all the analytics inside Fabric, a doubt arise. Should 1 model for all clients, and then have row level security, or for each client a semantic model?
the structure is the following:
Source data land into fabric, and are processed using a medallion architecture (bronze, silver and gold). Once reached the gold layer.
There are two level of data:
- Data that all clients have (contextual data) (for this is enogh filtering per client id just to have the data for that client)
- And client specific Data (different business rules, metrics etc)
I was trying to have one semantic model for all clients, but it seems that it add so much complexity, relationship etc
The reason why, we want one semantic model because it seems easier to maintain in terms of measures etc
But I do think it is better having indiviudal semantic models per each client, because I see the gain in easue of use, perfromance (less relationship etc) even if we lose a bit on resuability
Then, we want to create a standard dashboard that will have the same kpis for each client (but with the logic above), and even in that case I do believe to have separate semantic models.
I am a junior, so that is why I am asking, I am sure I will receive help from much more experienced ppl
Thanks.
Solved! Go to Solution.
Hi @robertozsr ,
This is a very common design question, and thereโs no single โalways rightโ answer โ it depends on how similar your clients really are.
If all clients share the same business logic, KPIs, and relationships, then a single semantic model with RLS can work well.
However, in your case you mention client-specific rules, metrics, and calculations. Once that happens, a single model usually becomes very complex: lots of conditional DAX, inactive relationships, heavy RLS, and harder performance tuning.
In practice, a separate semantic model per client is often the better choice:
Simpler DAX and relationships
Better performance (smaller, cleaner models)
Easier testing and troubleshooting
Safer changes (one clientโs change doesnโt impact others)
Reusability doesnโt have to be lost โ itโs best handled at the Gold layer (shared tables) and via model / DAX templates and naming conventions, rather than forcing everything into one model.
For standard dashboards, you can still reuse the same report layout and KPIs by binding the same report template to each clientโs semantic model.
In short:
same logic โ one model + RLS
different logic โ multiple semantic models
If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
Hi @robertozsr ,
This is a very common design question, and thereโs no single โalways rightโ answer โ it depends on how similar your clients really are.
If all clients share the same business logic, KPIs, and relationships, then a single semantic model with RLS can work well.
However, in your case you mention client-specific rules, metrics, and calculations. Once that happens, a single model usually becomes very complex: lots of conditional DAX, inactive relationships, heavy RLS, and harder performance tuning.
In practice, a separate semantic model per client is often the better choice:
Simpler DAX and relationships
Better performance (smaller, cleaner models)
Easier testing and troubleshooting
Safer changes (one clientโs change doesnโt impact others)
Reusability doesnโt have to be lost โ itโs best handled at the Gold layer (shared tables) and via model / DAX templates and naming conventions, rather than forcing everything into one model.
For standard dashboards, you can still reuse the same report layout and KPIs by binding the same report template to each clientโs semantic model.
In short:
same logic โ one model + RLS
different logic โ multiple semantic models
If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.
If I misunderstand your needs or you still have problems on it, please feel free to let us know. Thanks a lot!
Hello, thanks for the clear answer.
Can you expand a bit more on this two points:
- Reusability doesnโt have to be lost โ itโs best handled at the Gold layer (shared tables) and via model / DAX templates and naming conventions, rather than forcing everything into one model.
I can create a DAX template and reause?
- For standard dashboards, you can still reuse the same report layout and KPIs by binding the same report template to each clientโs semantic model.
It is possible to create a standard report, in terms of visuals etc? this means once the first one is created, I just basically have to copy-paste the report and attach to a different semantic model?
thanks!
The least number of semantic models, the less strain on resources. Also, the less places change has to be implemented.
Always strive for one model and multiple reports/dashboards off that one model.
Hello @robertozsr
You could consider a hybrid approach, where client-agnostic data is kept in a core semantic model with base facts and conformed dimensions, while client-specific thin semantic models hold client-specific measures. This architecture supports easier maintenance and offers extensibility in design.
Hello,
and it will be possible to attach two different semantic model to one report?
Hi @robertozsr
I wanted to check if you had the opportunity to review the valuable information provided by @deborshi_nag , @Thomaslleblanc , @ssrithar . Please feel free to contact us if you have any further questions.
Thank you.
If you love stickers, then you will definitely want to check out our Community Sticker Challenge!
Check out the January 2026 Fabric update to learn about new features.
| User | Count |
|---|---|
| 18 | |
| 5 | |
| 4 | |
| 3 | |
| 3 |
| User | Count |
|---|---|
| 62 | |
| 27 | |
| 14 | |
| 7 | |
| 7 |