Managing Tenant Settings in the Power BI Service

The tenant settings in the admin portal of the Power BI Service are incredibly important. The tenant settings include a wide-ranging number of things that significantly affect the user experience. It’s really important to manage the tenant settings effectively.In this post I’m going to talk about the process you should go through for reviewing and specifying your tenant settings.

The following is a high-level overview of what’s involved:

Diagram of analyzing tenant settings in the Power BI Service. What's the governance decision? Should the setting be enabled or disabled? Is it limited to specific security groups?

Let’s walk through the overview shown above.

Review Each Tenant Setting in the Power BI Service

We want to review each tenant setting specifically. This is really important to do as you’re initially getting started with your Power BI implementation.

It’s also really important to audit the settings on a regular basis. Quarterly works well. I’ll talk about that a bit further at the end of this post.

What’s the Governance Decision?

Each tenant setting really represents a governance decision. We want to check:

  • Is there an existing decision we can refer to? If so, that’s fantastic. Let’s use that and be consistent with what our established guardrails are. Our goal is to consistently encourage the type of data culture that we want to have.

  • Is a new governance decision required? If a new decision is required, that’ll require some conversations. Hopefully you have an executive sponsor involved and/or your Center of Excellence and/or BI team and/or IT and/or stakeholders where appropriate. The most important thing here is that a Power BI administrator usually shouldn’t be making decisions completely on their own about what tenant settings should be enabled, disabled, and for whom.

  • Will different teams be handled differently? Do you need to account for customizable policies and decisions for different teams? Although we like consistency where possible - we don’t like too much rigidity that’s overly inflexible. Customized policies and decisions are practical when you have decentralized self-service BI users, from different teams, who have different needs and skills. For instance, maybe the Operations team has a highly capable Power BI champion who is a satellite member of the Center of Excellence - this person might be allowed to do things that others aren’t. This means we’ve given them additional resources/support/information to operate with as much freedom and flexibility as possible, within the established guardrails.

A few examples of governance decisions that directly affect a specific tenant setting include:

  • Who is allowed to create a new workspace?

  • Who is allowed to certify content?

  • Who is allowed to create customized and personalized content using DirectQuery for Power BI datasets?

  • Who is allowed to discover the existence of content, if they don’t currently have access?

  • What type of custom visuals are allowed?

  • Who is allowed to publish content publicly on the internet?

    …just to name a few

Should the Setting be Enabled or Disabled?

With the information we obtained above, we have the first piece of what we need to determine what the setting should be in the Power BI Service. If the setting will be allowed (or disallowed) for the entire organization, we are good to go. Otherwise, we need to think about which groups of users (discussed next below).

This is a good time to mention not to go overboard with disabling features and functionality. For example, when I hear about people who recommend disabling all exports, or disabling downloads, the first thing I perceive is worry about is frustration.

I’ll be the first person to say that some settings should absolutely be very selective in who is allowed (for example: who is allowed to certify content).

However, I’m of the opinion that (usually) we want to encourage and enable users to get things done. This includes enabling things like exports and downloads so that people can be productive — with that said, I also think you should be analyzing your activity log regularly. If you see overuse of certain features you can talk to people and educate them on more efficient methods of working.

Is the Setting Limited to Specific Security Groups?

When a setting is to be applicable to a certain groups of users, here’s where we need to determine:

  • Does an existing security group exist which is suitable? Sometimes we can use standard organizational groups that already exist. Those are usually based on the org chart though, which means they don’t always line up well with what we want to do in Power BI.

  • Does a new security group need to be created (or requested)? When creating a new security group for this type of purpose, I recommend including “Power BI” in the name of the group so that its purpose is clear.

Screenshot from the tenant setting in the admin portal for "Create workspaces."

This screenshot shows an example of the “Create workspaces” tenant setting. The main security group I have allowed is:

  • Power BI Workspace Creators (this is a group created specifically for this tenant setting)

A few other existing Power BI-specific security groups are also allowed:

  • Power BI Administrators

  • Power BI Support

  • Power BI COE - Core (includes the centralized team members)

  • Power BI COE - Satellite (the decentralized members from other teams)

(Psst…There sure is a lot to think about with regard to Security Group Planning. I have a template for that in my Power BI Deployment and Governance online course.)

Just like users…having a group for your Power BI Administrators helps you manage which things they’re allowed to do in the tenant settings. Remember, an administrator does NOT automatically have permission to do all of the things specified in the tenant settings - they also need to be allowed by a group in the tenant setting. Having a Power BI Administrators group is also helpful for communication purposes, and for managing security settings.

Check out this post too: How Do You Manage Who is a Power BI Administrator?

Auditing and Reviewing Tenant Settings Regularly

It’s a good idea to audit / re-review your tenant settings every 3 months or so. Your goals are:

  • Verify all tenant settings. Double check settings are all exactly as you expect them to be. Nothing has changed since you last looked at them? No new groups have unexpectedly appeared since your last review?

  • Check for new tenant settings. New settings might have been introduced recently. There’s not always a huge announcement about new tenant settings, so you’ll want to plan to check regularly.

  • Update your tenant settings documentation. You do have tenant settings documentation for your internal users, right? (Psst…I have a template for that in my Power BI Deployment & Governance training course.)

  • Create a snapshot of your tenant settings documentation. Having a history of changes can be helpful sometimes.

Alerts When a Tenant Setting Changes

You can get alerts. For more info on what you can do, check out this post: How to be alerted when a Power BI tenant setting changes.

Finding More Information

About Tenant Settings

How to Be Alerted When Power BI Tenant Settings Change

How Do You Manage Who is Allowed to Be a Power BI Administrator?

Like this Content?

If you are responsible for overseeing and managing Power BI, you might enjoy our Power BI Deployment & Governance training course. We’re able to cover topics like what we discussed above more thoroughly. You’re able to jump on a group Q&A call with us every other week, and we have live workshops every month to work through something specific together. We invite you to check it out!