Let’s imagine you’re running a (fictive) company, and you’re short on data & analytics experts. Therefore, you decide to in hire expertise, and they will help you build your Power BI reports. As an employee of this organization, you rather have them starting sooner than later. But… if you need to request accounts for them at your IT organization, this might take weeks, if not a month to properly setup and run through this process. But what alternatives do you have?

In this blog I will further elaborate on the important things you should think about when working with Externals in Power BI. This blog is based on the session I’ve presented at the Dutch Power BI community day and at SQL Bits 2023 on the same topic together with my colleague Odeta Jankaitienė. =

Working with externals

What exactly are you talking about, that’s easy right? You just add a user and done?!

Well, that is not entirely the case. If you start working with externals in Power BI, there are many things to take into consideration before you start doing it. First of all, it starts with what exactly do you want them to do?

• Solely view and interact with content.
• Also build new content like reports and dashboards.
• Maybe even building entire datasets or datamarts.

Depending on what your goal is, a slightly different setup is the way to go. In the end, it all starts with having an account in the first place.

Let’s first talk a bit on the authentication to Power BI, before we talk on Power BI specifics like tenant settings and permissions.

Azure Active Directory

All authentication processes to the Power BI service, as well as other Microsoft services is handled by the central security and authorization mechanism. Azure Active Directory. In order to authenticate, your profile must be known in the directory. This can be either an organizational internal user, or an external guest account. Signing in is being done using a user principal name which belongs to an individual user. By using Azure Active Directory to sign in, all organizational standard security procedures will apply, like multi-factor authentication and other configurations.

For now, we take this as a given. In case you want to review more details on integration of Azure Active Directory and security, I recommend you read the Power BI Security whitepaper and/or watch below session by Kasper de Jonge on Power BI security deep dive which he presented at SQL Bits 2020.

Onboarding a guest

By adding a guest (external user) to your Azure Active Directory, there is a small process that can be followed. If you have sufficient permissions, you can easily invite an external user to your organization based on their mail address from the Azure portal. Review this documentation to see the exact steps to follow. The user will receive a mail like this to accept the invitation to your environment and have to enroll to your Azure Active Directory.

In the enrollment process, all your security standards will apply to their guest account. That means if you’re using multi-factor authentication, that will also apply to their guest account, despite what they have configured in their own environment.

In order to enroll as a guest into an Active Directory, the user must be part of an existing Azure Active Directory. If not, the user will be prompted to setup a tenant and identity.

After the enrollment of the user as guest user to your organization, the first step is done. However, the user does not have a license yet.

Licensing

Depending on what you want to do in Power BI, you need an appropriate license. As this blog is not a Power BI licensing deep dive, you have to bear with me a bit. We can distinguish two types of licenses:

• User based license: Free / Pro / Premium per User
• Capacity based license: Premium Capacity / Embedded Capacity.

Depending on your use case, one or another license type suits your situation better. To keep things a bit simpler, we could say that if the workspace in which your content resides is backed by premium capacity and users only consume the reports / dashboards, a free license will be sufficient. If users also need to build content outside their personal workspace, a Pro or Premium per User license is required.

As an organization, you might not want to put your licenses on guest accounts. However you can, the cost can add up pretty fast if you assign licenses for all your external users. Therefore, I recommend exploring if the external users already have a license assigned in their own company. If so, they could bring their own license and make use of that.

That brings the following part of the licensing flow in place, which follows directly on the authentication steps.

Tenant configuration

After all this is in place, there are a few Power BI tenant settings which apply to working with externals. This comes down to three standard principles:

• Do you allow people to invite guests (externals) to your organization?
• Do you allow guest users to access your Power BI tenant?
• Show Azure Active Directory Guests as suggested people when you type a name in the access menus of the Power BI Service (for example while sharing content or workspace permissions).

For each of these settings, you can limit them to a specific security group. So, if you are the tenant administrator, you do not have to give these permissions to the entire organization directly. If you made up your mind on above items, you still have to decide on a few specifics, to which extend you allow collaboration with externals in Power BI.

• Whether or not allowing Azure Active Directory guest users to edit and manage content in your organization.
• Can guest users work with shared datasets in their own tenants?
• Allow specific users to turn on external data sharing?

Again, you can limit this by security groups. I would strongly recommend doing that as soon as you enable any of the above settings. From a security and compliance perspective, you want to know where your data is and where it is being used and by whom. Therefore, I will not only recommend you limit these tenant settings by a security group, but also make each user aware, accountable and responsible for what they are doing when they share and collaborate with people outside the organization. Maybe let them do a small awareness test or sign a small agreement in which they consent to their responsibilities and accountabilities.

Besides that, I strongly recommend monitoring the Power BI Audit logs, as these also contain sharing information. Based on this information, you can see what content (which artifact in which workspace) is shared to whom and whether this is an external user. Consider setting up a process in which you let the owners of the content regularly review whether the permissions are still set correctly and whether these external users still require access or not.

Last but not least, in case you got export to Excel as a tenant setting enabled for example (I strongly recommend considering disabling this and rather go for analyze in Excel – see this blog post), be aware that these features are also available to your external users. I recommend disabling the majority of export functionalities for the Active Directory Group in which you maintain your external users. In that way, you can limit and prevent data leaving the organization. You can still allow your internal users to work with certain features, while externals are excluded from this.

The actual collaboration

When all this is done and in place, you can finally start your actual collaboration with externals. Depending on your use case, you can either choose your preferred way to share content being viewer permissions on workspace or publishing an app if users only need to consume content. Direct sharing it the report is also an option but be aware to select the option “specific people” before you can list external users. It is a best practice to share by publishing an app.

In case of collaboration on content in the workspaces, you can add the external users with appropriate permissions to the workspace. Admin permissions I would not recommend, as it would be odd if somebody outside your organization takes ownership over your content. Think about what level of permission they need and keep the principle of the least privilege as possible in mind. Don’t grant them more than they need, but just the bare minimum required to do what you want them to do.

Finally, if you also want external users to work with your datasets in Power BI desktop, be aware that this requires certain preview features (at the time of writing in March 2023) to be enabled in Power BI Desktop. Without these configurations enabled, external users will not be able to connect to your Power BI datasets from Power BI desktop.

Also, keep in mind that as soon as you connect from Power BI Desktop to a dataset that lives outside your tenant, the connection will not be a live connection, which would be the default in connecting to datasets in your own tenant. The connection will automatically change to be a DirectQuery connection. With that, DirectQuery and composite model limitations apply. Review the two links below for the specifics.

• General limitations DirectQuery.
• Limitations DirectQuery to Power BI datasets.

Now, all options are detailed out, this final part will help you in deciding which permissions you need to grant for your use case.

As a final thing, in the scenario where you want your external users to also publish content to your organization. There is a little trick you can apply to allow users with guest accounts to publish content to the workspaces they have access to with appropriate permissions with their guest account. This trick is nicely explained in below Guy in a Cube video.

Wrap up

When you start working with externals, it all starts with the challenges of requesting accounts for external experts from the IT organization, which might take you a lot of time. In case you want them to work with their own user accounts, they must be enrolled as a guest to Azure Active Directory, which is the central security and authorization mechanism for all authentication processes to the Power BI service and other Microsoft services. Further, licensing is another key consideration, as external users may require an appropriate license depending on their use case. Last but not least, thing about what collaboration and input you expect from your external users, as specific tenant settings apply which might block them from doing certain things.

As a tenant administrator, make the right considerations when it comes to your tenant configuration. Do you even allow external collaboration? If you do, think about the effect on other tenant settings that you might need to adapt. Further, build a process around the onboarding of external users and think about monitoring and regular reviews of external permissions.

Having all the options in place and the overview of all that needs to be done to get this working, you might ask yourself if this is really faster and smoother than requesting that account for your external consultants at your IT organization. Well, it all depends…

Resources

I’ve listed various resources throughout the blog. I want to list the most important ones below:

• Power BI Security whitepaper
• SQL Bits 2020 – Kasper de Jonge – Power BI security deep dive
• Guy in a Cube – Publish from Power BI Desktop for external users
• Distribute Power BI externally using Azure Active Directory B2B

Finally, you’ve seen parts of the decision tree that helps you to make the right considerations and decisions. To geta full picture of all elements and how they relate together, you can work with the full decision tree as shown below. Also, you can find editable draw.io files in this GitHub repository.

Final words

Some final works of gratitude. Although, I put this blog together, all content is based on a collaboration with Odeta Jankaitienė. My colleague at Macaw and co-presenter for this session at various events. Odeta also started her own blog. I recommend you have a look there too!