Manage workspaces and datasets in Power BI VI

In this Learning Path, you'll learn how to publish Power BI reports to the Power BI service. You'll also learn how to create workspaces, manage related items, and data refreshes for up-to-date reports. Additionally, implement row-level security to restrict user access to relevant data without the need for multiple reports.

Introduction

You've likely had the chance to load and transform data from numerous sources, build visuals, create DAX equations, and even publish a report or two to Microsoft Power BI. The next step on your data analysis journey is to share these reports with your wider audiences and organizations. You can accomplish this task in a workspace, which is a feature of Power BI. A workspace is a centralized repository in which you can collaborate with colleagues and teams to create collections of reports and dashboards.

Workspaces offer the following benefits:

• Focused collaboration efforts. You can use workspaces to house reports and dashboards for use by multiple teams.
• Ability to share and present reports and dashboards in a single environment.
• Assurance that the highest level of security is maintained by controlling who can access semantic models, reports, and dashboards.

This module will discuss several tasks that are focused on helping you to create and manage a workspace in Power BI. Additionally, you will learn about importing and updating assets in a workspace, configuring data protection, troubleshooting data, and much more.

Distribute a report or dashboard

Completed100 XP

• 7 minutes

Consider a scenario where you have created a few reports for the Sales team at Tailwind Traders. The issue that you have encountered is determining how to make these reports viewable and shareable. By creating a workspace in Power BI, you can house your reports in one location, make them shareable, collaborate with other teams, and update reports.

Create a workspace

Your first task is to create a workspace by following these steps:

1.                  Go to Power BI service.

2.                  Select the Workspaces menu from left navigation blade.

3.                  Select the Create a workspace button at the bottom of the resulting panel.

4.                  In the Create a workspace window, enter information in the Workspace name and Description fields and then upload a Workspace image.

5.                  In the Advanced drop-down menu, you can create a Contact list of users who will receive notifications if issues with the workspace occur.

By default, these users are the workspace admins, but you can also add specific users. You can also add this workspace to a specific OneDrive and then choose whether this workspace will be a part of a dedicated capacity or not. Dedicated capacities are Power BI Premium features that ensure that your workspace will have its own computational resources as opposed to sharing resources with other users.

6.                  After you have filled out pertinent fields on the Create a workspace window, select Save.

You have now created a workspace.

Assign workspace roles

Now that you've successfully created a workspace, the Sales team wants to collaborate with other teams to build additional dashboards and reports. As the workspace owner, you want to ensure that appropriate access is given to members of the Products team because their team includes stakeholders and developers. Workspace roles allow you to designate who can do what within a workspace.

There are four roles for workspaces, and it's advised that you grant the minimum access necessary to collaborators. For consumers, skip workspace role assignment, and provide access through the app instead in the next section.

The four roles are listed below, in order of most permissive to least, along with select permissions. For full permissions, review the Roles in workspaces documentation.

• Admin
• Update and delete the workspace
• Add or remove people, including other admins
• Member
• Add members or others with lower permissions
• Publish, unpublish, and change permissions for an app
• Contributor
• Create, edit, and delete content, such as reports, in the workspace
• Publish reports to the workspace
• Viewer
• View and interact with an item
• Read data that's stored in workspace dataflows

 Note

If the workspace is backed by a Premium capacity, a non-Pro user can view content within the workspace under the Viewer role.

To assign these roles to users, go to the workspace that you've created and, in the upper-left corner of the ribbon, select Access.

In the resulting Access window, you can add email addresses of individual users, mail-enabled security groups, distribution lists, Microsoft 365 groups, and regular security groups, and then assign them to their specific roles. You can also change the user's assigned role at the bottom of the page and delete the user from the workspace by selecting the ellipsis (...) next to their name.

Create and configure an app

After creating an app workspace and assigning your collaborator-specific roles, you want to add content to your app workspace. Content can be in the form of reports, dashboards, semantic models, dataflows, and so on.

An app is a published, read-only window into your data for mass distribution and viewing. When ready to share apps with your users, you can publish the app. This process requires a Power BI Pro license. Consuming and viewing an app also requires a Pro license, or the workspace must be hosted in a Premium capacity.

You can now publish from Power BI Desktop to your new workspace, and upload saved files or create new items from within the workspace.

When you are ready to publish your app with its collection of reports, dashboards, and semantic models, return to the workspace and select Create app in the upper-right corner of the ribbon.

The Build your app experience starts on the Setup page, where you add a name and description for the app. You can also customize the theme color and add a logo if desired.

 Tip

Use the Contact Information and Support Site fields to help users contact the appropriate person(s) and how to find help for the app.

Under the Content tab, you can choose which content to include and change the viewing order. You can add content in the workspace, new sections for grouping, and external links.

In the Audience tab, you're now able to choose one or more audiences with different viewing options.

First, you'll select which reports you want visible to the default audience created. Select what content each audience sees by toggling the eye icon on the right. In the following screenshot, the audience is called "Sales" by default, but you can right-click and rename it.

After selecting the viewable content, you can Manage Audience Access. You can Grant access to the Entire organization or Specific users or groups. For Specific users or groups, you can enter any mail-enabled account accessible within your Power BI tenant.

In the Advanced section, you can choose to grant additional permissions, individually or neither:

• Allow people to share the semantic models in the app audience
• Allow people to build content with the semantic models in the app audience

Lastly, notice that Workspace users are already included in the audience by default. This goes back to the roles we covered earlier.

 Note

Entire organization may not be accessible due to settings configured by your Power BI Administrator. Additionally, not all email addresses may be available, such as external accounts.

When you're ready, select Publish app. Congratulations, you just published an app! You'll receive a notification with the link to distribute to consumers, and an option to go to the app.

 Note

When publishing, there's a notification that it may take 5-10 minutes or longer to reflect changes, depending on your tenant and size of report. It's not possible to guarantee changes will be reflected in 10 minutes or less.

Update workspaces

After publishing your app, you realize that you want to make updates within your workspace.

Don't worry, it's as easy as publishing your app. From the workspace, the Create app button will now say Update app. Select Update app, then move to the appropriate section and make your changes. When ready to save your changes, select the Update app button in the bottom where Publish App was before.

Monitor usage and performance

Completed100 XP

• 2 minutes

Knowing about the usage and performance of your workspace is crucial because it:

• Focuses your efforts for improvement. If you know the areas that experience the worst performance, you can concentrate your efforts for improvement in those areas.
• Quantifies the impact of your reports. Usage metrics help you determine your reports' success.

These performance and usage metrics are available features that you can use in a workspace. With these metrics, you can view who's using your reports, what actions are being done on the reports, and what performance issues exist.

For example, consider the continuing scenario where you work for Tailwind Traders. You've successfully added reports to your workspace, published an app, and begun the process of collaborating with the Products team. Commentary begins to circulate around the company about how useful these workspaces are, resulting in more users being added to the workspace. The Sales team knows that performance might worsen with the increased addition of users. Consequently, the Sales team has asked you to monitor usage and performance of the workspace.

Configure and view usage metric reports

Usage metric reports are available for Power BI Pro users and can only be accessed by users with the role types of Admin, Member, or Contributor.

To view usage metric reports, go to the pertinent workspace. Find the report or dashboard that you want to see usage metrics for. For example, if you want to see the usage metrics report for Sales Data, select the ellipsis (...), and then select View usage metrics report from the drop-down menu.

When the usage metrics report is ready for viewing, you will receive a prompt that will direct you to a dashboard. In the Report usage tab, you can view such details as:

• Viewers per day, Unique viewers per day (which doesn't include users who returned to the same reports multiple times), and Shares per day charts
• Total Views, Total Viewers, and Total Shares KPI cards
• Total views and shares ranking (compares how your report is doing in comparison to other reports in the app)
• Views by Users (details about each specific user that viewed the dashboard)

You can also filter by the distribution method of the report (for example, through sharing or from the workspace directly) and platform type (for example, mobile or web).

You can also view performance metrics on the Report performance tab, as shown in the following screenshot.

On the Report performance tab, you can view metrics such as:

• Typical opening time - How long it takes, at the fiftieth percentile, to open the report.
• Opening time trend - How the typical opening time changes over time. This metric can tell you how the report is performing as the number of users starts to grow.
• Daily/7-Day Performance charts - Highlight the performance for 10, 50, and 90 percent of the open-report actions every day and over a seven-day period.
• Filters for date, so you can see how the performance changes according to the day.

Recommend a development life cycle strategy

The development process is iterative; it typically requires building an initial solution, testing the solution in a different environment, returning to make necessary revisions, and eventually releasing a final product. This process is known as a development life cycle. This process can take place in several different ways and in different environments.

To continue with the module scenario, the Sales team at Tailwind Traders is impressed with the reports that you have delivered, and as they continue to use the abilities of Power BI, they also want to maintain data and report integrity without slowing development timelines. As a result, they have asked you to create a development pipeline that will be used by all teams to develop reports and dashboards. Power BI provides deployment pipelines that you can use to help accelerate development and minimize errors.

Deployment pipeline (Premium)

The deployment pipeline feature in Power BI manages content in dashboards, reports, and semantic models between different environments in the development life cycle. With this feature, you can develop and test Power BI content in one centralized location and streamline the process before deploying the final content to your users. This Power BI Premium feature requires you to be a Capacity admin.

The advantages of using the deployment pipeline are:

• Increased productivity - Through this feature, you can reuse previous deployment pipelines, ensuring that efforts aren't duplicated.
• Faster delivery of content - Report development becomes more streamlined, meaning that it takes less time to get to production.
• Lower human intervention required - Having the ability to reuse deployment pipelines means a decreased chance of error associated with moving content from one environment to another.

Development environments

Typically, development and collaboration occur in different stages. Reports and dashboards are built in and iterated on a series of controlled stages, or environments, where several tasks occur:

• Development - The location in which dashboard developers or semantic modelers can build new content with other developers. This stage is first in the deployment pipeline.
• Test - Where a small group of users and user acceptance testers can see and review new reports, provide feedback, and test the reports with larger semantic models for bugs and data inconsistencies before it goes into production.
• Production - Where an expansive user audience can use tested reports that are reliable and accurate. This stage is the final one of the deployment pipeline.

You can choose which one of these development environments that you want to include in your deployment pipeline, according to your business needs. For example, you can choose to only include the Test and Production environments, if necessary.

Configuration of deployment pipelines

In the scenario with Tailwind Traders, you want to create a deployment pipeline. To configure a deployment pipeline, go to Power BI service, and then follow these steps:

1.                  On the ribbon on the left side of the page, select Deployment pipelines, as shown in the following screenshot.

2.      On the resulting page, select Create a pipeline.

3.      Create a deployment pipeline called SalesPipeline. Enter the Pipeline name as SalesPipeline and enter a description, if necessary.

4.      Select Create, which will take you to the following screen.

This view shows you the steps of the development life cycle: Development, Test, and Production.

5.      To create your pipeline, assign workspaces to each of these stages to facilitate where your reports and dashboards will be housed during each stage.

6.      Select Assign a workspace to begin.

7.      You will be directed to the Assign the workspace to a deployment stage window, where you can add the Tailwind Traders workspace to the Development environment.

Only workspaces that are assigned to a Premium capacity will appear. Additionally, you can only assign a single workspace to each pipeline. Power BI will auto generate the two other workspaces that are used in the pipeline.

8.      If you already have Development, Test, and Production workspaces, choose one that you want to work with and then select Assign.

If this step is successful, you should see the resulting view.

The preceding image shows how many semantic models, reports, and dashboards that you have in the current Development environment. At every stage, you have the option to publish the associated workspace as an app by selecting Publish app.

9.      To view all objects that constitute the workspace, select Show more.

Testing stage

After you have collaborated with the teams and built a testing-ready report, you are ready to proceed to the testing phase. Select Deploy to test, which will create a new workspace. This workspace, by default, has the same name as the initial workspace but includes the [Test] suffix. You can change the name by entering the workspace's settings within the deployment pipeline interface.

Testing should emulate conditions that objects will experience after they've been deployed for users. Therefore, Power BI allows you to change the source of data that is used during testing. To accomplish this task, you will first need to enter the environment's deployment settings by selecting the lightning icon, as shown in the following screenshot.

In the resulting Settings window, select the correct semantic model. In this example, you want the OrdersFigures semantic model to be used for testing but with a different data source. To accomplish this task, create parameters in Power Query Parameters (which will be discussed in a later module) or add a new rule, which is the process that is used for this example. Under the Data source rules drop-down menu, select + Add rule.

On the Data source rules section, you can change the data source (which was used in development) to a new source, which is used for testing the reports (orders.csv in the following example). When you are finished, select Save at the bottom of the card.

Production stage

Now, you are close to completing the pipeline, transitioning from development to testing, and finally to production. At this stage, you need to create a data source rule for the OrdersFigures semantic model in the workspace to ensure that you are using production data. In this instance, you will be changing your source from the test to the production folder version of the orders.csv file, as shown in the following screenshot.

After performing a semantic model refresh, your production workspace will be ready. You can package the workspace as an app, which is available for users. Currently, your deployment pipeline will appear as shown in the following figure.

You have successfully created a deployment pipeline from the development to the testing phase. The following section describes additional operations that you can conduct in the development pipeline.

Additional operations in the development pipeline

You have created a deployment pipeline and have begun collaborating with other report developers. You receive notification that one of the other developers has modified a report. To see the changes to this report, select the Compare button, as shown in the following screenshot.

Selecting Compare reveals that the OrdersFigures report differs between the Development and Test environments.

The difference is typically registered as added or removed objects. If you decide that the changes shouldn't be deployed to the next phase, you can choose to ignore the changes. For instance, the other developer has added a report called AdditionalOrderInfo in the Development environment, but you don't want to deploy these changes. By selecting a specific report and then selecting Deploy to test, you can effectively choose which reports that you want to move from environment to environment, as shown in the following figure.

As the following message indicates, only one change will be carried over.

Exercise caution with this tool. Reports are dependent on their semantic models. If a semantic model has changed, but you don't deploy it with an associated report, the report will not behave correctly.

We recommend that you use deployment pipelines in Power BI service. This tool ensures that the development life cycle is streamlined and that you can create one centralized location to collaborate, keep track of, and deploy your reports.

Troubleshoot data by viewing its lineage

Completed100 XP

• 6 minutes

The Lineage view feature in Power BI allows you to quickly refresh semantic models and see the relationships between the artifacts in a workspace and their external dependencies.

Consider this module's continuing scenario with Tailwind Traders as an example. Thus far, you've developed several reports and have published them to the Tailwind workspace. However, because you are also collaborating with the Products team, it has become increasingly difficult to track which reports need to be refreshed and which semantic models are in which report. Consequently, you want the ability to determine which semantic models need to be refreshed because you've been receiving reports of stale data. The path of data from its source to the destination can often be a considerable challenge, more so if you have multiple semantic models.

The Lineage view feature can help you accomplish this task efficiently and almost effortlessly.

Data lineage

Data lineage refers to the path that data takes from the data source to the destination.

The Lineage view feature in Power BI is crucial because it:

• Simplifies the troubleshooting process because you can see the path that the data takes from source to destination and determine pain points and bottlenecks.
• Allows you to manage your workspaces and observe the impact of a single change in one semantic model to reports and dashboards.
• Saves time by simplifying your task of identifying reports and dashboards that haven't been refreshed.

Use the Lineage view

The Lineage view is only accessible to Admin, Contributor, and Member roles. Additionally, it requires a Power BI Pro license and is only available for app workspaces. To access the Lineage view, go to the workspace, and then select Lineage from the View drop-down menu on the top ribbon.

When the view canvas opens, you can begin to explore this view. The following example shown an excerpt of the data lineage for the Tailwind Sales workspace.

This view shows all the artifacts in your workspace. Artifacts include data sources, semantic models and dataflows, reports, and dashboards. Each card represents an artifact, and the arrows in between these cards represent the flow of data or the relationship between different artifacts. By following the arrows from left to right, you can observe the flow of data from the source to the destination, which will often be a dashboard. Typically, the flow would be data sources > semantic models/dataflows > reports > dashboards.

Data sources

Each of the following cards is a data source that is used in your workspace.

The card tells you the type of data source (for example, Text/CSV) and the Gateway, which tells you the source of your data. If you are connected to the data through an on-premises data gateway, this card will tell you more information about the gateway. Additionally, if you double-click the card, you will get more details about the data source, such as the file path and the connection status.

Selecting the lower-right icon on the card will highlight the path from the data source to the destination, as shown in the following screenshot, which clarifies the exact path that the data takes.

Next are the semantic models/dataflows, which are marked in blue.

semantic models/dataflows

Often, semantic models and dataflows can connect to external data sources, such as SQL Server, or to external semantic models in other workspaces. The following examples show semantic model and dataflow cards on the Lineage view.

The Lineage view uses arrows to connect objects, such as semantic models, with their data sources. On these cards, you can see when the semantic model was last refreshed, and you can refresh the semantic model by selecting the arrow icon on the lower-left corner of the card, as shown in the following screenshot.

This component is a powerful troubleshooting feature that helps ensure that your semantic model refreshes are quick and uncomplicated.

Returning to the initial quandary with Tailwind Traders, you wanted to determine if the company had stale semantic models and then quickly refresh the data. By using the Lineage view feature, you can go through the different semantic models in one view and then use the Refresh data button to refresh semantic models that you determine as stale.

Additionally, if a semantic model or dataflow belongs to a different workspace (in this case, the Tailwind workspace), it will be indicated on the card, as shown in the following screenshot.

By double-clicking on any card, you can view the metadata, such as the sensitivity, by whom it was configured, the last refresh date, and the names and count of tables within this semantic model, as shown in the following figure.

You can also view the impact of this semantic model across workspaces. By selecting the overlapping window icon on the lower-right corner of a semantic model card, you can determine the impact analysis of the semantic model.

On the Impact analysis window, you can see how many workspaces, reports, and dashboards that this semantic model is a part of and how many views that this semantic model has gathered, as shown in the following screenshot.

The bottom of the Impact Analysis window includes more detail about which specific reports and dashboards that this semantic model is part of. Additionally, you can select Notify contacts, which allows you to notify semantic model owners (or any other user) of changes in the semantic model. Impact analysis is useful because it allows you to pinpoint semantic models that aren't being used or looked at.

Reports and dashboards

The reports and dashboards cards have similar functionality as the data source and semantic model cards.

Selecting a card will bring up a window in which you can view the metadata about the report or dashboard. In this window, you can also go directly to the report or dashboard. You can also enable or disable whether you want to include this report or dashboard within the app.

This card also contains useful options under the ellipsis (...), as shown in the following figure. From this menu, you can select to analyze the report in Microsoft Excel, delete a report, create Quick Insights, save a copy to a workspace, and more.

Now that you have had an in-depth look into the Lineage view in Power BI, you can commence with cleaning up the Tailwind Traders workspace. For more information, see Data Lineage.

Configure data protection

Completed100 XP

• 2 minutes

As enterprises grow, so does their data. Often, strict requirements and regulations must be applied to ensure that this sensitive data is secure. Power BI provides a few different ways to help you accomplish this task:

• Use Microsoft sensitivity labels to label dashboards, reports, semantic models, and dataflows by using the same taxonomy that is used to classify and protect files in Microsoft 365.
• Add more protection measures such as encryption and watermarks when you are exporting the data.
• Use Microsoft Cloud App Security to monitor and investigate activities in Power BI.

To continue with the module scenario, as more reports and dashboards are increasingly added to the Tailwind Traders workspace, the Sales team becomes concerned as they realize the urgency of securing their data. The team is concerned about the possibility of new users exporting data without permission. The Sales team doesn't want to roll back reports or dashboards, so they have asked you to implement comprehensive security measures that protect data access within and outside of Power BI. You can complete this task by configuring data protection labels in Power BI.

Before you begin, ensure that you have the appropriate licensing, as shown here.

Sensitivity labels

Sensitivity labels specify which data can be exported. These labels are configured externally to Power BI, and Power BI allows you to quickly use them in your reports and dashboards. These labels allow you to define and protect content, even outside of Power BI. semantic models, dataflows, reports, and dashboards can use this mechanism, and all users in your corporation can use this feature unless exceptions have been defined.

After you have verified your ability to add labels, go to any workspace and choose an object to secure. For this example, you will add a sensitivity label to Sales Data by going to the workspace and, under the ellipsis (...), selecting Settings.

This selection will take you to a window, where you can assign a sensitivity label to your data. For this example, the following labels have been externally configured, so you can now apply them to the data: None, Personal, General, Confidential, and Highly confidential. You can also go to Microsoft 365 Security Center to define your own labels.

For example, if you want to assign a Confidential label to your Sales Data report, when you change this label on the Settings pane, it will appear as a label on the report, as shown in the following figure.

This factor is crucial when you are exporting data. Data that is exported to Microsoft Excel, Microsoft PowerPoint, and PDF files will have sensitivity labels enforced. For instance, if you wanted to export data from Sales Data into an Excel file, if you are an authorized user, you will see the following Excel view when you export into Excel.

However, if you didn't have established permissions, you would be denied access to see the data. This verification ensures that only appropriate users have access to view the data, which helps make sure that your data is secured.