3 min read

Organising assets and access control in MS Fabric

Organising assets and access control in MS Fabric

This article is a direct follow up from my previous blog post where I laid out my approach to the Medallion Architecture and how I see it fit in Microsoft Fabric. I would recommend you have a quick look at it here before reading this article.

In this blog post, I will show you how I would go about organising all those assets we talked about previously to ensure the right people have the right level of access to what they need while promoting self-service where possible.

Note: The scenarios and diagrams in this article are highly simplified. In reality, there would be a lot more assets to manage. This article aims at explaining my philosophy when it comes to managing assets in Fabric and provide access to them.

Quick reminder on the Fabric Workspace roles

In this article, I will mention Fabric Workspace roles. For detailed information about what they are, head over to the official documentation, but the table below sums it up pretty well for the purpose of this article:


Typical approach: A single workspace to rule them all (kind of)

Let’s first go through a scenario I've seen too often and unpack its downfalls.

In this scenario, we have a single Fabric Workspace that contains all our assets, including all the assets we talked about for our Medallion Architecture.


At a first glance, it makes it easy to access everything you need, but the workspace gets cluttered pretty quickly (even though Microsoft have just announced folders in workspaces, I don’t think that will solve the underlying problem).

But when we start looking at access control, this is where things get a little dicey.

If we want to allow a data engineer to do their work, they will need at least contributor access to this workspace. This will also give them access to create, modify or even delete Power BI assets such as datasets, reports, dashboards.

Similarly, we probably want data analysts to have contributor access as well. This means they will also be able to create, modify or delete data engineering assets such as pipelines, lakehouses, warehouses, notebooks etc…

This might not be an issue if you have a well behaved team where individuals are aware of their boundaries, but even then, I guarantee that when the next big deadline approaches and a data analyst needs a new column in their dataset and the data engineer is off sick, there will be some tinkering happening.

I’ve seen examples where data consumers are being given Member access to a workspace to make it easier for them to have access to what they need. This gives me shivers! I’ve witnessed business critical reports being broken or completely wiped accidentally because of that.

Because at the time of writing, there is no feature in Fabric to manage access control on the different experiences of Fabric (Data Factory, Data Engineering, Data warehouse and Power BI), we need to take a different approach.

A better approach to organising assets

The key things we are trying to achieve here are:

  • Ensure an efficient way of managing access and permissions on our assets

  • We want to promote and cultivate visibility throughout the end-to-end process within the data team

With that in mind, a better approach would be to split each layer of the Medallion Architecture in their dedicated workspaces and add a consumption workspaces to better manage content delivery to the data consumers.


This approach provides the following benefits:

  • Each workspace has a dedicated purpose, in line with the medallion architecture

  • Access to control to the different assets is made a lot easier by segregating assets in different workspaces

Coming back to our scenario earlier, we can now grant data analysts contributor access to the Gold and Consumption workspaces. They will not be able to impact the Bronze and Silver workspaces.

We can also provide our data engineers contributor access to Bronze and Silver without them being able to impact Gold and Consumption workspaces.

The table below shows how I would go about granting different persona access to the individual workspaces:


There are a couple of things I would like to point out here:

  • Data consumers should not be given access to any of workspace in itself, but instead the associated app

  • Data engineers are granted viewer access in Gold and Consumption; Data analysts are given Viewer access in Bronze and Silver. This is to ensure transparency and promote openness in the broader data team. It feel it is important for a data analyst to understand how the data is being ingested and transformed and for a data engineer to see how the data is presented and consumed.

Coming up next:

In the next instalment of this series, we will deep dive into the Bronze layer and explore how to efficiently ingest data into Fabric.

I’m curious about what you think. Please leave a comment below or reach out!

Managed Identity Authentication with Azure REST APIs and Azure Container Apps

Managed Identity Authentication with Azure REST APIs and Azure Container Apps

As part of an engagement with a client, I had to write guidance around using Managed Identity when interacting directly with Azure REST APIs on Azure...

Read More
Medallion Architecture Meets Microsoft Fabric: Insights and Fiction

Medallion Architecture Meets Microsoft Fabric: Insights and Fiction

Microsoft wants to recreate the undeniable success of Power BI but with a wider data remit by including Data Engineering, Data Warehousing and Data...

Read More
Ride the agile wave - Remote Agility

Ride the agile wave - Remote Agility

Hey there! Let’s chat about something cool – how you can bring the Agile Manifesto to life while working remotely, using your everyday internal team...

Read More