We can say Fabric is the evolution of the Power BI environment.

Power BI is a self-service environment, and so is Fabric. This allows the implementation of very interesting architectures, which will be the subject of future videos and articles.

However, it’s not something free-and-easy, and it shouldn’t be. Using Fabric Admin Portal (or Power BI Admin Portal? It’s starting to be confusing) you can control who will have access to create Fabric objects.

We have the following possibilities:

• Leave it enable for the entire organization. It will become free-and-easy, I don’t recommend.
• Specify the groups which can create Fabric objects
• Specify groups which can’t create fabric objects

In general, the best option is to define “who can”, instead of “who can’t”. I would love to hear about exception scenarios for this.

Fabric is integrated with Azure Active Directory (ops… Entra IDs). In this way this permission control integrates with your organization permissions and you can define which teams can create Fabric objects by creating Entra groups (Active Directory groups).

This self-service approach is a great match with Data Mesh architecture. I’m promissing for a while, soon an article about it will be available. Meanwhile I will be talking about it at Power BI and Fabric Summit or in person at Pordenone Data Saturday.

Team leaders responsible for specific domains can raise their hand and ask the permission to create Fabric objects for their team, allowing them to create the single source of truth for their domain.

There is also the possibility to link this to the commercial aspect: Each domain team leader may be responsible for their own Fabric capacity. In this way, they become the administrator for their Fabric capacity and this global permission allows the Power BI Administrator to delegate to the capacity administrator the permission to create Fabric objects.

Administration, Commercial and Data Architecture have a match at this point.