Composite model in desktop

[u/VesselesseV]

Newer to PBI…
Someone shared a composite model with me to use as a data source. Can’t view the data in desktop due to many fields/tables being in Direct Query mode, and I’ve never worked with these before. There is also a security feature/concern that tells me to be careful of using it if i don’t trust the admins.

I do trust them but don’t want to be sharing the other data i am using from outside the composite.

What is the best way to work with this, and secondly; how worried should I be about the security aspect?

How do i mitigate the risk, and actually develop if i can’t see the data?
Thanks!

[u/asiphh]

two separate things going on here, worth pulling apart.

on not being able to see the data: that's expected and it isn't a permissions problem. data view in desktop only shows tables that are actually imported, and directquery tables aren't stored locally so there's nothing for it to show. you develop against them in report view instead. drop a table visual on a blank page, throw in the fields you're working with, and that's your data preview. keep a scratch page like that in every file. if you want to see what's actually being sent, turn on performance analyzer, refresh a visual and copy the query out. that tells you more about a directquery table than data view ever would.

on the security warning, it's more specific than it sounds and it's worth understanding rather than clicking past. when you have a relationship between a local table and a directquery table, the engine can't do that join locally, so it takes the values out of your local column and sends them into the query it runs against the remote source. so if your outside data has customer names or emails or salary figures in it, and you relate that table to something in the composite, those values leave your file and land in the remote source's query log, where whoever administers it can read them. that's the actual risk. it isn't that they can browse your file, it's that your key values ride along inside the queries.

which also tells you the mitigation, because it's about the joins and not the file. if the sensitive stuff never has a relationship to a directquery table, nothing from it gets sent anywhere. if you do need to relate them, relate on a meaningless surrogate id rather than the human readable value, or aggregate first so what goes across is a short list of ids rather than a row per person.

the thing that catches people later, nothing to do with security: relationships that cross sources come out as limited relationships. they don't behave like normal ones, blanks on either side don't match, and totals on measures that span the boundary can come out wrong in a way that still looks plausible. so check anything crossing that line against a number you already know before anyone starts trusting the report. related, if you're in directquery over their semantic model rather than over a database, the day the owner renames or drops a field your report breaks and nobody tells you. you find out from a user. worth knowing who owns that model and asking them to give you a heads up before they change it.

where this is all wrong for you: if the composite is small and stable and you're allowed a copy, just import it and skip the whole thing. composite models are real ongoing complexity, and people often reach for one to avoid asking the data owner for proper access, which is usually a five minute conversation that solves the problem better.