We have decided to split the measures into different custom tables because it is currently not possible to hide measures or folders. With this approach, we can then hide all measures not related to Sales by not importing the other custom tables in the Sales dataset.
The Sales dataset can direct query on this dataset & nitpick the needed tables & measures:
This has the advantage of maintaining only one version of the truth – The Operations dataset - and answers the need of splitting the user base across different workspaces & reports.
If IT decides to add a new table, column, or measure in the Operations dataset, it will automatically synchronize across all relevant datasets, simplifying the maintenance across all domains immensely.
If you want to avoid adding extra tables automatically to your sub-dataset, you can simply uncheck the “Include tables added later” box.
A salesperson can now access the “Sales Workspace” & see their own “Sales dataset” relevant to him.
A power user who requires the need to do cross-domain reports will then connect to the operations dataset.
At the moment of writing this insight, the feature is still in preview.
I’ve occasionally encountered some broken visuals, which usually get resolved by refreshing the dataset.
In terms of pure performance, you will suffer a hit on your DAX statements due to the direct query component, but it is most of the time negligible if you are using relatively simple visuals & reports.
It can become noticeable if you consume & create heavy reports with complex row context calculations (think the SumX function on massive tables or reports with 25-30+ visuals for example).
To my surprise, any metadata change will not automatically be pushed toward the lower-level dataset.
If you, for example, add a new measure in your Operations dataset, you’ll have to download your sales dataset, refresh it, and republish it to the sales workspace to be in sync and see this new measure appear in your report.
This can become cumbersome if you iterate a lot on your model and have to keep all your child datasets in sync.
Final thoughts & conclusion
As explained in the introduction, this approach is not meant to secure datasets: For the dataset to be accessible, the user needs to have read & build access to the original dataset. We are not effectively preventing access to the original workspace & dataset.
In conclusion, while we are diverting a bit from the initial intent of the feature, this allows a great deal of flexibility with workspace & dataset management.