Stop sharing workspaces and start delivering polished, governed report experiences with Power BI Apps. This hands-on lesson walks you through building, configuring, and publishing an enterprise app — including audience groups, navigation design, and seamless update workflows.
Imagine you're the lead BI developer at a regional healthcare network with 3,000 employees. You've spent weeks building a beautiful, accurate set of Power BI reports — a hospital operations dashboard, a staffing utilization report, and a patient outcomes tracker. You share the workspace with your team, and then the chaos begins: nurses are bookmarking the wrong version, department managers are confused about which report is "official," and IT keeps getting tickets from people who can't find the dashboard they need. You've built something great, but distribution is breaking the whole experience.
This is the exact problem that Power BI Apps were designed to solve. A Power BI App is a polished, packaged container that bundles your reports and dashboards into a single, branded experience — then delivers it cleanly to hundreds or thousands of consumers without exposing the messy internals of your workspace. By the end of this lesson, you'll know how to create, configure, and publish a Power BI App, how to manage audiences and access, and how to maintain and update your app as your reports evolve. You'll also understand why the architecture works the way it does, which means you'll be able to adapt it to your own organization's needs.
What you'll learn:
Before diving in, you should have:
Before building an app, you need to understand a fundamental architectural decision in Power BI: workspaces are for creators, apps are for consumers.
Think of a workspace like a kitchen. It's where the prep work happens — the raw ingredients (datasets), the in-progress dishes (reports being revised), and the professional staff (your BI team) who are constantly tweaking things. You wouldn't seat restaurant guests in the kitchen. The dining room — clean, curated, and controlled — is where they go. In Power BI, the app is your dining room.
When you share a workspace directly with a colleague, you're giving them kitchen access. They can see every report, including the half-finished prototype you built last Tuesday. They can accidentally click into the dataset settings. They can't easily tell which dashboard is the "official" one. This approach works for small, technical teams — but it scales terribly.
A Power BI App solves this by publishing a curated snapshot of selected content from your workspace. Here's what that means in practice:
This separation is not just cosmetic — it's a governance feature. It means your development team can continue iterating in the workspace while consumers enjoy a stable, clearly labeled experience.
Publishing a Power BI App follows a clear sequence that's worth understanding before you click anything:
Notice that step 5 is separate from steps 1 and 2. This is intentional. When you update a report in the workspace, those changes are not automatically visible in the published app. You must explicitly republish the app to push changes. This is a feature, not a bug — it gives you a "staging" buffer where you can revise reports without prematurely exposing half-finished work to thousands of employees.
Let's walk through the process using our healthcare network example. Assume you have a workspace called Healthcare Operations that contains three reports: Hospital Capacity Dashboard, Staffing Utilization Report, and Patient Outcomes Tracker.
In the Power BI service (app.powerbi.com), open the left navigation panel and click Workspaces, then select Healthcare Operations. You'll land on the workspace content list, where you can see all your reports, dashboards, and datasets.
Near the top right of the workspace view, you'll see a button labeled Create app (if no app exists yet) or Update app (if one was previously published). Click Create app. This opens the App setup panel, which has three main tabs across the top: Setup, Navigation, and Permissions.
The Setup tab covers the basics of your app's identity:
Tip
Take the description seriously. Users who find the app through Power BI search will read this description to decide if it's the one they need. Ambiguous descriptions lead to support tickets.
The Navigation tab is where the real curation happens. This is where you decide what users see and how they move through it.
On the left side, you'll see a panel labeled Content that lists all available reports and dashboards from your workspace. On the right, you see a preview of the app's navigation structure.
To add a report to the app, click Add content and select the report from the list. You can rename it for the app's navigation — for example, your report might be internally called v3_staffing_final_USE_THIS_ONE, but in the app, you can rename it to simply Staffing Utilization.
You can also:
Warning
If you don't add a report to the app's navigation, it won't be visible to app users — even if it exists in the workspace. This is by design. Don't forget to explicitly include every report you want consumers to see.
The Permissions tab controls who can access the app. This is one of the most important tabs, and it's worth spending time here.
You have two primary options:
Option 1: Entire organization — Anyone in your Azure Active Directory (now called Microsoft Entra ID) tenant can find and install the app. Use this for truly company-wide content, like a corporate KPI dashboard that every employee should reference.
Option 2: Specific individuals or groups — You manually specify users or security groups. This is the right choice for most enterprise scenarios, where not every employee should access every app.
For the Healthcare Operations Hub, you'd likely add:
clinical-staff@healthcarenetwork.com (a security group containing all nursing and clinical staff)operations-managers@healthcarenetwork.com (a security group for administrative leadership)Best practice
Use security groups rather than individual users whenever possible. If you add 200 individual email addresses, maintaining that list becomes a nightmare. A security group managed by IT means users automatically gain or lose access when they join or leave a department — without you touching the app at all.
You can also control whether app users can share the app with others or build their own reports on top of the app's datasets. For most large-scale consumer scenarios, leave both of these unchecked to maintain control over your data distribution.
For more complex organizations, a single permission set isn't enough. What if you want the clinical staff to see the staffing report but not the detailed patient outcomes data — because that report contains information restricted to physician-level staff?
Power BI Apps support multiple audience groups, which let you publish different subsets of content to different user segments — all within the same app.
Here's how it works: In the Permissions tab, instead of using the default single audience, you can click New audience to create multiple groups. Each audience group can have its own:
For our healthcare example:
A user assigned to "Operations Managers" will install the app and only ever see the two reports you've designated for them. They won't know the Patient Outcomes Tracker exists within the same app. This is a powerful governance capability that saves you from having to build and maintain separate apps for every role.
Tip
If a user belongs to multiple security groups that map to multiple audience groups, they'll see the union of everything those groups are allowed to see. Plan your audience groups with this in mind.
Once Setup, Navigation, and Permissions are configured, click the Publish app button at the bottom right of the panel. Power BI will validate your configuration and then publish.
After publishing, you'll see a confirmation screen with a shareable link to the app. This link is the URL users can use to install or access the app directly. Copy it and include it in your announcement email, SharePoint page, or internal communications.
When employees click the link, they'll be prompted to install the app into their Power BI home. After installation, the app appears under Apps in their left navigation pane. From that point on, they open the app directly — they don't search for individual reports.
One of the most common questions from new Power BI developers is: "If I update my report in the workspace, does the app update automatically?"
The answer is nuanced. Report content — the visuals, data, and measures inside a report — updates automatically because the app points to the live report in the workspace. If you refresh your dataset and the numbers change, those updated numbers will appear in the app immediately.
However, structural changes — adding a new report to the app, changing the navigation structure, modifying permissions, or renaming sections — require you to explicitly republish the app. Here's the process:
When you republish, users don't lose anything. They don't need to reinstall the app. The next time they open it, the updated navigation and content are already there. This seamless update experience is one of the key advantages of the app model over direct sharing.
Warning
Don't delete a report from your workspace that's currently included in the app. If the underlying report is deleted, app users will get an error when they try to open that section of the app. Always remove a report from the app's navigation and republish before deleting it from the workspace.
Let's put this into practice. This exercise assumes you have a Power BI Pro license and at least one workspace with a published report.
Scenario: You're a BI developer at a regional retail chain. You have a workspace called Retail Analytics containing three reports: Weekly Sales Summary, Inventory Levels by Store, and Customer Loyalty Metrics.
Your task:
Open the Power BI service and navigate to your Retail Analytics workspace (or create one and publish a report to it if you haven't already).
Click Create app from the workspace toolbar.
In the Setup tab:
In the Navigation tab:
In the Permissions tab:
Click Publish app and copy the link.
Open a new browser tab, paste the link, and install the app. Notice how the navigation appears, how the default page loads, and how different the consumer experience feels compared to the workspace view.
Go back to your workspace, make a visible change to one of your reports (change a chart title, for example), then reopen the app. Notice that the content change appears without republishing. Then add a note or subtitle to the app description and republish — observe how the app updates for consumers.
Mistake 1: Publishing the app but forgetting to add reports to navigation Users open the app and see a blank navigation panel. Solution: Go to Update app, navigate to the Navigation tab, and confirm that your reports are listed there. Simply existing in the workspace is not enough.
Mistake 2: Adding individual users instead of security groups You add 150 individual email addresses. When an employee leaves and their account is deactivated, you have to manually remove them. When a new hire joins, you have to manually add them. Use security groups managed by your IT or HR systems instead.
Mistake 3: Assuming workspace viewers can't see the workspace If a user has Viewer role in the workspace and access to the app, they can access both. If you want strict separation between creator space and consumer space, don't add app consumers to the workspace. Manage their access exclusively through the app.
Mistake 4: Deleting reports from the workspace without removing them from the app first Users get a "Content not available" error. The fix is to update the app navigation to remove the deleted report, then republish. Prevention is better: always remove from app first, then delete from workspace.
Mistake 5: Expecting structural changes to update automatically A developer adds a brand new report to the workspace and emails the team saying "it's live in the app." But it won't be live until they republish. Always republish after structural changes.
Troubleshooting: Users say they can't find the app Check two things: First, confirm the user's email or group is listed in the Permissions tab. Second, remind them to look under the Apps section of the Power BI left nav, not under Workspaces. Many new users look in the wrong place.
Troubleshooting: Users see different content than expected If you're using audience groups, verify which group the user belongs to. Remember that users in multiple groups see the union of all allowed content. If a user shouldn't see a specific report, make sure none of their groups grant access to it.
You now have a complete, practical understanding of Power BI Apps — what they are, why they exist, and how to build and distribute them at enterprise scale.
The core ideas to carry forward:
Next steps to deepen your skills:
Building a great report is only half the job. Getting it to the right people, in the right form, with the right access — that's where enterprise BI developers earn their keep. Power BI Apps are your primary tool for doing that well.