Build access to a subset of a model

[Johan_1234]

Is there any way to give a user build access, but only to a subset of a semantic model? I.e. not all tables and columns.

I have a model with many tables and I also have power bi reports which use that model as their datasource. Users have access to the reports but no direct access to the model.

Now I want to give a few users permission to create their own reports and to connect to the model from Excel. However, I don't want them to access the whole model, there are a few tables which I don't want them to have access to. Is there anyway to achieve this?

So far I have though of a few approaches on how to give these users build access which all seem to fail for various reasons:

* Create a perspective for a subset of the model. - Doesn't work since the default perspective will still be available.

* Create a separate subset model and connect to the big model with direct query and only include some of the tables. - Doesn't work since the users need to have build access on both models.

* Use Object Level Security to limit the access to some tables to the users with build access. - Doesn't work since that also means that the reports that use those tables fail for theses users.

Thank's in advance for any suggestions.

[V-yubandi-msft]

Hi @Johan_1234 ,

May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.

Thank You.

[Johan_1234]

I have not resolved this issue. Not in a very satisfactory way anyway. Currently I'm considering setting visual=false for all tables/attributes which should not be available for adhoc use. 

[danextian]

One option is to create a new semantic model that uses DirectQuery to connect to the existing semantic model and select only the required tables. However, this method isn't foolproof, as permissions still depend on the original semantic model.

Another approach is to connect through the XMLA endpoint and import only the needed tables — this is possible if the workspace is in Premium capacity.

If neither option is available, the alternative is to create a copy of the original PBIX file, remove the unnecessary tables, and share that version with users as suggested by the other users.

[Johan_1234]

Thanks @danextian , what do you mean with "connect through the XMLA endpoint" approach? Create a new import mode model which reads from the original model?

My model is on a capacity workspace.

[V-yubandi-msft]

Hi @Johan_1234 ,

This means you can connect to your original Power BI semantic model using the XMLA read/write endpoint, available if your workspace is in Premium or Fabric capacity. With tools like Tabular Editor, Visual Studio, or SQL Server Management Studio (SSMS), you can explore and manage the model behind the scenes, similar to how you’d work with Analysis Services models.

You're correct you can use this connection to build a new import mode model that includes only the tables and columns you want. Since it’s a separate model, users with Build access will only see what you’ve included, and nothing from the original that you’ve left out.

I hope this gives you better clarity. If it answered your question, feel free to mark my reply as the accepted solution

[rohit1991]

Hi @Johan_1234 ,

Unfortunately, right now there’s no way to give Build access to just a part of a semantic model anyone with Build rights can access the whole thing, regardless of perspectives, OLS, or hidden tables. It’s definitely a pain point.

The only safe way at the moment is to create a separate, trimmed-down model that only includes the tables and columns you want those users to access. Publish that to its own workspace and give Build permissions there. I know it’s not the most convenient solution, but it’s the only approach that actually secures the data.

All the other tricks like perspectives or hiding tables just change the report experience, but don’t stop someone with Build rights from seeing everything in the model using tools like DAX Studio or Tabular Editor.

The good news is Microsoft is actively working on more granular security (like OneLake Security), so hopefully this gets easier in the near future. 

[andrewsommer]

The most straight forward and safest method would be to create a new semantic model with only the tables and fields you want users to see (a completely new model, not a subset of your current model).  Give users access to this model only and then existing reports continue using the original, unrestricted model.

If your users with build rights are less technical then you could also try hiding the tables in the model, so they do not see them when they connect.  However, this doesn’t restrict their access to the data, it is purely a UX simplification.  With that said, from my experience it is enough for many users particularly when your security needs are not regulatory in nature.

Please mark this post as solution if it helps you. Appreciate Kudos.

[Johan_1234]

Thanks for your reply Andrew,

I guess a separate model would be the "last resort" solution. I was really hoping that there were some way to achieve my goal with the available security model without going down that road. Creating a separate model would be pretty painful with separate routines for managing source code, deployments, refreshes etc. 

[andrewsommer · Accepted solution]

Unfortunately, right now there is not a better option.  However, Microsoft does have a solution coming for this issue and many more.  They are completely overhauling Fabric with OneLake Security currently in private preview. 

Please mark this post as solution if it helps you. Appreciate Kudos.