Domains

At the same time, the necessity for developers to have separate environments is also growing. We need them to determine what data they should be working with quickly. We also want to eliminate the possibility of them having access to data they should not be able to see.

In addition to this, I have already come across requests calling for possibilities to somehow “label” the workspaces according to which department owns them. Why? The reasons vary:

• ability to distribute the licensing cost between departments that use it,
• ability to tell which department has the most content,
• possibility to compile a guide/dashboard (report) for users, leading to their reports
• …

Until now, it could have been solved by various alternatives, such as prefixes or suffixes in the names of the workspaces or the Description. At some point, we got the option to extract this information via the Power BI REST API. Of course, this meant setting up processes that prevented the transcription of these characters/names and ensuring we had the information needed. It was still a WORKAROUND, after all.

But! Here comes a novelty in the form of DOMAINs, which could replace this workaround with a native way, as it should be! So what are domains, how do they work, and are there any limitations? That’s the question! Let’s take a closer look and answer all the basic questions.

Domains introduction

Domains (Microsoft Fabric Domains, to be precise) represent the possibility of grouping workspaces into logical units, such as departments. As a result, everything located in the given workspace will also automatically be stored under the given domain. It sounds like what I described a bit above as an increasing need. But there is one limitation that must be mentioned! One workspace can only be in ONE domain!

The fact that we would mark the workspace with a domain would solve only part of the problem. That’s why we must look deeper and see if they cover other scenarios. So, for example, does the user recognize that the workspace is added to a domain? Are we going to be able to sort the content with them? Is it possible to get them with API? Can we set it up so developers see only what they should see (artifacts, not rows, tables, etc.)?

The simple answer to the first question is YES. Each workspace can be recognized as being added to a domain, and each of them will be tagged:

Domain Logo on Workspace

Unfortunately, this tag cannot be changed. Yet. We need to determine at first glance whether the workspace belongs to the Controlling or Finance domains. Hopefully, one day, we will have this option. But it does not leave us entirely in the dark. Hovering over this icon, the following tooltip will appear, telling us much more.

Logo tooltip

But I have already gone into detail and will reply later. This view will mostly bother us only if we have access to workspaces, which only some users may have, but of course, developers do. But let’s look at domains from three perspectives: Admin, Developer, and User.

Admin perspective

From an admin point of view (Microsoft Fabric / Power BI Admin), I’m interested in how domains are created, managed, and audited. So let’s start by creating a domain.

Domains in Admin Portal

From a process perspective, it’s a very simple procedure:

1. A new category has been added to the Admin Portal: Domains
2. In it, there is a button ”+ Create a new domain.”
3. A new menu will appear. There you can fill in the name and description. For example, I will create a Domain called BoD (Board of Directors) for demonstration purposes. Name and Description
4. Then we can choose an image that the domain will carry with it. Where? Within OneLake Data Hub for now. Domain Image
5. The selection is not great, and you can’t even upload your picture, but we are at the beginning, and hopefully, we will get more options further along. Select from Images
6. Finally, we can set up the Domain manager. It is important to know that the admin only has permission to enter assigned workspaces if this permission has been explicitly granted to him. So, you don’t have to worry about the domain admins having the ability to get to places they should not have access to. It‘s a good idea to consider to whom we assign this permission because this person can add or remove any workspace from this domain. At the same time, the Domain Admin can access the Admin Portal, specifically the domain settings, but he will only see the domains he manages! It’s not like he has the authority to change everything. Technically, he can only edit the Description of his domains here. Domain Admins
   • How the domain admin sees the Admin portal: Domain Admins Perspective
   • Admin can edit the description of the domain and assignment of contributors, but he cannot edit, delete or add additional admins. Updates that Domain Admin can do
7. In addition to Admins, we can assign another kind of permission to users within the domain – the contributor role. We can add or remove workspaces with this role, but only those we manage entirely because they are done directly inside workspace settings. This means that the given user has to be a Workspace admin to add or remove a domain to the workspace. However, he cannot add users to this role or change other main domain settings. Domain Contributors
8. The last step is the assignment of the workspaces themselves. This can be done both here, from the Microsoft Fabric / Power BI Admin Portal, or directly in the settings of each workspace. I will return to the settings within the workspace because the settings from this environment can do a few extra things! Assign workspaces
9. After clicking “Assign workspaces,” we can choose how we want to add them - we can add workspaces individually or in bulk. Types of assignment
10. The first option is quite clear. Explicitly by name, we will add a workspace to the domain. But the other two options are the interesting ones! Why? Because they can make bulk changes. But that’s not all! It could create some trouble. Because what would happen if the workspace part of the current adding was already part of another domain? Then it will be reallocated to this domain, which can cause us to place our workspace in the wrong domain accidentally. AD the limitations I mentioned at the beginning. So watch out for that!
    • Assign by workspace admin will allow us to assign all workspaces where the selected user is in the role of workspace admin. There is one exception. The user’s “My workspace” will not be assigned to this domain. At the same time, you need to be careful if we control Domain Contributors using security groups, for example, this user will also be added as a Contributor! Assign by Workspace Admin
    • Assign by capacity works very similarly. Of course, we are not talking here about adding anyone to the Contributor role, but about the fact that “My workspace” (supported by capacity and it does not matter whether it is a Premium Per User or a full-on license, such as P1) will not be added to this domain. Assign by Capacity
11. But if you expect that when I set up the Controlling domain to contain workspaces from Capacity “P1 – Controlling,” every new workspace will be automatically assigned to this domain, then, unfortunately, you expect something that will not happen. This addition operation is a one-time operation and does not constitute a rule that would enable this automation. Therefore, it is necessary to modify the process of creating workspaces, specifically by expanding these domains. But once I’m assigned, everything is done. Not really. That is it from a production point of view.

But what about adding a workspace to a domain from its environment? Even easier. We have to distinguish whether we are establishing a given workspace or already modifying it.

If we are creating, we can select the domain directly in the opening window: Create new workspace

If we are editing, open the workspace settings and select the domain we want to assign in the About section. Update current workspace

But what´s next? Administering the domain is relatively simple because the same interface that guided us through production allows us to edit anything. The biggest change or expansion displayed here is for connected workspaces. We can disconnect the workspace from the domain, either one workspace at a time or for all selected ones. Fortunately, there is also an option to filter by keyword based on the workspace’s name. So if you need to filter out a pattern and your company uses a naming convention, this field should help you find it quickly. Unassign workspace from domain

We currently have one last Admin request left. This makes it possible to audit these domains and associated objects. Is it okay? YES! First of all, I would like to introduce you to the new admin to Power BI REST API:

curl --location 'https://api.powerbi.com/v1.0/myorg/admin/domains' \
--header 'Authorization: Bearer XXXXXXXXXXXXXXXXXX'

This API call, which also supports ServicePrincipals, can return individual domains that exist in your company: Returned domains

Great. An easy way to list them. Most admins probably thought by now that using an API call to workspaces, either ”./admin/groups?$top=XXX” or ”./admin/groups/{group-id}”, we can get to this ID within individual workspaces. Unfortunately, I will disappoint you! Even if you add the HTTP Query ”?$expand=*“, you cannot get the domain assigned to the workspace. But we may get there one day. Fortunately, there is another variety here. ScannerAPI. This Power BI REST API branch already has this data ready for us. We must carefully get the “domainId” attribute from the ScanerAPI, which comes as “objectId” from the Domain endpoint. ScannerAPI response

So? I find it quite remarkable! All Admin requirements are met. This will help to simplify the management of the Service interface because it will be possible to divide individual domains between admins and monitor them in parts. The necessity to add prefixes/suffixes to the name only to assign workspaces under some cost units/departments will disappear. At the same time, I can imagine a very simple report that, thanks to this native capability, will tell which department uses the most capacity / by what percentage, and how much it should pay. I also welcome the possibility of grouping domains into domain units. For example, the domain unit would be HR, with subdomains L&D, Hiring, Employee, Satisfaction, etc. It would provide a higher level of detail. Still, I believe the query on ”./domains” is only about one more table, enabling the mapping to a higher aggregation category.

Developer Perspective

As a developer, I am primarily worried about whether this extension will make developing new datasets easier. So far, the answer is quite uncertain, either yes or no. Why? Because from the developer’s point of view, today, there is an option to “filter” datasets/lakehouses/datamarts/data warehouses only to a specific domain. But this filtering only applies if we are within the Microsoft Fabric. Within Power BI Desktop, this division does not work yet, so if you select the option to get data from the Data Hub within Power BI Desktop, everything will look like before: Data Hub in Desktop

In the same way, the possibility of publishing according to the AVAILABLE domains has yet to arrive. Maybe one day. This would help prevent someone from uploading the report+dataset to the wrong workspace. But what does it mean that we have a domain available? After all, even as admins, we didn’t deal with anything like access to the domain so far!

Suppose you are a user with access to the workspace (both directly or indirectly using a security group) within a domain. In that case, you automatically get the option to access this domain. But you will get to only some workspaces or all datasets placed in the relevant domain. So it still stands that you only have access to workspaces where you have been assigned at least the Viewer role.

In the picture below, you can see that within the Data Hub, the domain we created was reflected in the dropdown, where if we select this domain, its name, description, and the image will be displayed. In addition, under this upper banner, the available data content of the given domain will be displayed within the Recommended and Selection sections. OneLake Data Hub in Service

Unfortunately, that’s all for now from the role’s point of view. For now, the user has it the same as the developer. Because so far, the domains have yet to be reflected in the filters or the Browse options. One day it will happen, and we will talk a lot about the influence of domains on ordinary users.

Roles within domains

In the process of identifying individual requirements and fulfilling them, I came across the following roles:

• Power BI Admin
• Domain Admin
• Domain Contributor
• Regular User

You can find an overview of their capabilities here:

* They can only override those settings that the Power BI Admin allows them to

Summary

Domains are a well-started variant for sorting content between individual larger units. This possibility will not only help large companies to find their way around their content and assign the proper departments to it but also for smaller companies to realize who owns which data and who accesses it. Thus, in the future, it could lead to a higher readiness for self-service, which is highly desired in many companies.

At the same time, I also see the potential for consulting companies that could use this function to develop products/solutions. For them, it could be an exciting tool to categorize and prepare the created content for specific audiences from individual departments. For both the salesperson and the developer, it could then function as a tool for finding solutions that meet the currently addressed requirements.