Would handy is there was also a way to reference views from workspace to workspace similar to shortcuts but can’t see a way so far

@Julio Ochoa Hi, yes you are correct, views are just logical joins of tables so in theory to be able to reference them from other workspaces would mean you need to bring in all the underlining tables used by the view as shortcuts too. However there are scenarios when using warehouses (more likely in Gold layer) where you want to reference just a view from another location workspace/warehouse especially if you need to expose a flat data view for business users when using a semantic model may not be ideal. My understanding is shortcuts are just persisted tables which are copied over from the source in the background and managed by delta log changes thereafter, in theory making views also persisted in this way should be possible.

I recently finished a contract working on a Fabric implementation and have been trying to find a new contract opportunity but have been surprised with the lack or opportunities in UK at the moment, it seems it’s still just a bit too new for demand to be realised, hopefully will change over the next few months 👌

@Justin Stevenson I think that’s a fair point however I also believe there is a fundamental gap in skill inbetween the data engineering side of things and the Power BI development side. I’ve worked a lot with the arguably now outdated SSIS/SSAS toolset and one area I’ve seen being somewhat neglected is the modelling side of things, whether that’s due to lack of experience from developers or because it’s easier to cover up poor performance from bad model design with increased cpu power that the cloud offers I’m not sure, I suspect a little bit of both. The one thing Fabric offers which I think is understated at the moment is that SQL Managment studio experience wrapped over the performance benefits of a delta lake. This makes it easier for old school seasoned SSAS developers to break into the modern stack of Fabric and be able to create well modelled warehouse fact/dimension tables outside of PBI and leave the PBI developers to focus on the DAX and visual side of things, right now it just seems data goes from Data engineers and then gets picked up PBI developers with a lack of attention for the modelling side of things. Quite a ramble so apologies 😆

I also think Fabric hugely increases adoptability of cloud/data lake implementation for businesses that maybe didn’t have the in-house python and architecture skill sets for developing a data lake solution. One of the biggest wins for Fabric is that it effectively gives you a SQL server wrapper over the data/delta lake solution, making it very flexible and much easier for experienced on-prem SQL server developers to make that shift, just my thoughts anyhow 🙂

I do think there is an in between role that is valid, an Analytics engineer, someone who knows modelling and is responsible to bring in the data from silver layers into gold layer/reporting layer. Data engineers may not always appreciate the nuances of data transformation from silver data into a star schema model, data analysts may also not be experienced enough in the specifics of how best to design star schema tables but are experts in using the modelled data and applying more complex calculations on top of it.

@Eivind Haugen thanks for the link, we currently working on a meta data driven solution to improve our implementation. However it would be good to look at actually potential creating all objects for an environment purely in code, so you could actually create/spin up an entire environment at will just from meta data. I think being able to create workspaces from some form of base template would be interesting, currently I see a gap in being able to easily create test workspaces with data for development purposes

That’s interesting will check it out, many thanks!

Fabric has CDC functionality in Delta tables, might make sense making use of that for their implementation