Welcome to part three in our series on Microsoft Fabric governance, where we apply principles we’ve learned from our work in Tableau to Power BI and the broader Microsoft Fabric ecosystem. In part one, we covered basics about users, roles and capabilities. In part two, we discussed strategies for organizing and subdividing content. And in part three, we’ll provide some tips for managing your content lifecycle using techniques like content promotion, certification and deployment pipelines.

Power BI Offers More Options To Draw Users’ Attention to the Content That Really Matters

Tableau introduced data source certification a few years ago, which was a helpful way to ensure people were using the “single source of truth” for their reporting. Power BI has a similar certification concept within Microsoft Fabric, but it extends beyond data sources and can be applied to reports as well. (Note: If you don’t have the option to certify content, it’s because Fabric admins have not yet granted you that capability.)

Power BI also allows you to “promote” content, which is really just a label that you can apply to important content. The certify option is intended to indicate that content has been through a specified approval process. Promoted content does not have to go through that same process, but might be applied if you have new content you want to draw users’ attention to, or perhaps content that is timely at certain points in the year. You can also choose to show promoted content in the featured section of the Fabric home screen to help users notice it.

Above: Power BI allows you to apply tags like Promoted or Certified to reports and semantic models

One other helpful feature in Fabric is the option to make semantic models discoverable. This allows users who don’t have access to a semantic model to see that it exists and request access.

Above: Making semantic models discoverable allows users to find and request access to relevant data sources

Power BI Has a More Structured Approach To Deploy Content Through Stages

One essential governance principle we recommend to all clients is having some sort of development to production process. In Tableau, we generally recommend having separate dev and prod projects (folders) to separate content in development from content ready for analysis. The process of moving content from dev to prod is somewhat informal and manual though (literally just moving content from one folder to the other or publishing to the prod folder after content has been approved). Tableau also has a content migration tool, which can be used to move content between different sites if clients choose to separate dev and prod content by sites rather than by projects (folders), but that tool is generally reserved for more complicated deployments and not used by the average developer.

Power BI in Fabric, however, has a more structured content deployment option called Deployment Pipelines. When you set up a deployment pipeline, you can choose which stages you need (dev and prod are the basics but you can add other stages if you’d like to):

Each stage can then be assigned a workspace in Fabric:

Once your stages and workspaces are assigned, you can compare content within two work spaces and choose to deploy all content or select individual pieces of content to move from one workspace to the other. If the content does not already exist in the target workspace, Fabric will create a new copy of it in that workspace. If the content already exists, Fabric will overwrite it with the current copy from the previous stage.

In the example below, I connected two workspaces that weren’t true development and production environments, but you can see that Fabric easily shows the differences between the two workspaces and allows me to easily update content in the production workspace by simply selecting it and clicking deploy:

Fabric also lets you establish rules to help with your content deployment. For example, stages might need to point reports to different databases or switch from a sample of data in a development space to full data in a production space. Rules allow you to change these settings while keep other aspects of the content in sync. Deployed content inherits values defined in the deployment rules, and Fabric maintains those rules for future deployments as long as rules remain unchanged and valid. Microsoft has several helpful articles explaining nuances of deployment pipelines. This article is a good one to start one if you’d like to dig deeper.

Tableau and Power BI Both Have Lineage Views That Help Manage Changes

One last feature that can help you manage content lifecycles is the lineage view, which is available in both Tableau and Power BI/Fabric. These lineage views allow you to see connected content and determine which content may be affected by changes to objects further upstream.

Tableau’s lineage view is a little bit less visual, but is probably better suited to display the connections between a large amount of content. The sidebar shows a visual summary of connected content. Clicking on the various items (workbooks, sheets, etc.) returns a list of everything in that category.

Above: Tableau’s lineage view

Power BI’s lineage view actually visualizes the connections between every piece of content in a workspace. This is easy to use with a smaller amount of connected content, but it might become rather cumbersome if your workspace grows. Also note that at the time of writing this, there didn’t appear to be an easy way to detect connections across workspaces within Fabric (it is possible to share semantic models across workspaces so there may be connected reports in other workspaces).

Above: Power BI’s lineage view within Fabric 

Wrapping Things Up

That wraps up our brief series on governance tips for Microsoft Fabric (at least for now…we may have more thoughts to add later). We hope this series has provided some thoughtful tips and helped you understand the ways you can govern content in both Tableau and Power BI within Fabric.