Publishing, Sharing, and Your Capstone Dashboard

The report is done. You connected the data, cleaned it, built the model, and laid out visuals that finally make the numbers make sense. It looks great on your screen. The problem is that right now it lives only on your screen.

Your manager wants to see it. Three colleagues need it every Monday. The regional leads each want their own slice. And the whole thing has to stay current on its own, because you are not going to rebuild it by hand every week and email a fresh file to a dozen inboxes.

This chapter is how you get from “a file on my laptop” to “a live dashboard my team opens whenever they want, always up to date.” Then you put the entire Power BI workflow together in one capstone project of your own.

Why this matters

A report nobody can reach is a report nobody uses. The last mile, getting your work in front of the right people in a way they can trust and return to, is where Power BI stops being a personal tool and becomes something a team runs on.

It is also where mistakes get expensive. Emailing files means five versions floating around and nobody sure which is current. Careless sharing puts numbers in front of people who should not see them. Skipping the refresh setup lets your “live” dashboard go stale, and someone decides on last month’s data.

Getting this part right is what separates a nice-looking chart from a dependable source of truth.

Publishing: from your laptop to the service

Everything you have built so far happened in Power BI Desktop, the free app on your computer. To get your work online, you publish it to the Power BI Service, the web version that runs in your browser at app.powerbi.com.

Publishing is one button. In Power BI Desktop, on the Home ribbon, select Publish. Sign in if it asks, then choose where to send it.

Two things travel up when you publish. Your report, meaning the pages and visuals people look at. And your semantic model, meaning the cleaned tables, the relationships, and the measures underneath it. The report is the storefront; the model is the warehouse behind it. Both land in the Service together.

One thing to know early: changes you make in the browser do not flow back to the file on your computer. Your Desktop file stays the master copy. To update the published version, edit in Desktop and publish again, which replaces what was there.

Workspaces and apps: the shelf and the finished package

When you publish, Power BI asks which workspace to publish to. A workspace is a shared area where a team keeps related reports, dashboards, and models together.

Everyone starts with My Workspace, a private area only you can see. It is fine for drafts and practice. For anything a team shares, you create a named workspace, something like “Sales Reporting” or “Operations Dashboards,” and publish there so the right people can find it in one place.

A workspace is the room where the people who build and maintain reports work together. But most people who need your dashboard should not be poking around a room full of half-finished drafts and raw data models. That is what an app is for.

An app is a clean, packaged version of selected content from a workspace, published out to the people who just need to view it.

Think of the workspace as your kitchen and the app as the finished plate you send to the dining room. People who receive an app see a tidy set of reports with easy navigation. They cannot see the messy back end, and they cannot change anything. You can even set up different audiences in one app so the finance team sees finance pages and the sales team sees sales pages, from the same package.

The plain rule: build and collaborate in a workspace, distribute to a wide audience with an app.

Once your content is in a workspace, you decide who can do what. Power BI gives a workspace four roles, from most powerful to least.

Admin. Full control, including managing who else has access.
Member. Can edit content and share it with others.
Contributor. Can create and edit reports, but cannot manage access.
Viewer. Can open and interact with reports, and nothing more. They cannot change anything or reach into the underlying data model.

The guiding idea is least access: give each person the lowest role that still lets them do their job. Someone who only needs to read a dashboard gets Viewer, never Member. It is the same logic as not handing out a master key when someone only needs the front door. A role that is too generous risks more than accidental edits; it can let someone see or export data they were never meant to touch.

For quick sharing you do not always need roles. You can share a single report or dashboard directly with a named person or group, the simplest way to get one thing in front of one colleague. For a broad, ongoing audience, an app is cleaner. For a small team working closely together, workspace roles fit best.

Try It Open a report you built in an earlier chapter (or make a quick one from any sample data). Then:

In Power BI Desktop, select Publish on the Home ribbon and send it to My Workspace.

Go to app.powerbi.com in your browser and find it. Open the report and click around. Notice it behaves just like it did on your desktop.

Find the Share button at the top of the report. Open the share dialog and read the options, including whether recipients are allowed to reshare. You do not have to send it to anyone. The goal is to see exactly what you would be handing over before you ever hand it over.

What did you notice about the difference between the report and its semantic model in the workspace list?

Keeping the data fresh: scheduled refresh and the gateway

A published report shows the data as it was the moment you published. To keep it current, you set up a scheduled refresh, which tells Power BI to go pull the latest numbers on its own, on a timetable.

You set this on the semantic model in the Service. Open the model’s settings, find Schedule refresh, turn it on, and pick your times. On standard (shared) capacity you can schedule up to eight refreshes a day; on Premium capacity you can schedule up to 48.

For many sources this just works. If your data lives in the cloud already, in a service Power BI can reach over the internet, refresh runs without anything extra.

The catch is on-premises data, meaning data that lives on your own company’s servers or a database behind your office firewall. The Power BI Service is out on the internet and cannot reach inside your network on its own. To bridge that gap you install a small piece of software called the on-premises data gateway on a machine inside your network.

Picture the gateway as a trusted courier standing at your building’s door. The cloud service asks the courier for the latest figures, the courier fetches them from inside, and hands them out safely. No gateway, no way to refresh from that internal source, and your dashboard slowly goes stale.

The concept to carry away: cloud data usually refreshes on its own; data on your own servers needs a gateway.

Row-level security: the right rows for the right people

Sometimes everyone opens the same report, but each person should see only their own slice. The Western manager sees Western numbers, the Eastern manager sees Eastern numbers, nobody sees the whole company. Rebuilding a separate report per region would be a nightmare to maintain.

Row-level security, or RLS, solves this. It filters the rows a person can see, based on who they are, inside one single report.

Here is the plain version. In Power BI Desktop you create roles with a rule, for example a “West” role that shows only rows where the region is West. You publish, then in the Service you assign real people to each role. When a Western manager opens the report, Power BI quietly applies the West filter and they only ever see Western rows. Same report, personalized view, no extra copies.

One important detail: RLS filters apply to people in the Viewer role. People with edit-level roles (Admin, Member, Contributor) see everything, because they need the full data to build with. So the people you want to restrict should be Viewers.

You do not need the exact steps today. Just know the capability exists and what it is called, so when someone asks “can they each see only their own accounts?” you know the answer is yes, and the tool is row-level security.

Sensitivity labels: a tag that travels with your data

Some reports carry sensitive information: salaries, patient counts, deal pipelines, personal details. Power BI can attach a sensitivity label to a report or model, a tag like Confidential or Highly Confidential, drawn from your organization’s Microsoft Purview labels.

The label does two jobs. It marks how sensitive the content is, so people handle it with care. And, crucially, the label travels with the data when it leaves Power BI. If someone exports a labeled report to Excel, PowerPoint, or a PDF, the label and its protection come along, so a “Confidential” export stays confidential and can be set so only people inside your organization can open it.

This is usually set up by your IT or security team, and applying labels typically needs a paid license and organization settings turned on. As a report author, the idea is what matters: a label is protection that sticks to your data even after it leaves the dashboard.

What Power BI costs

Licensing trips people up, so here is the plain-language version. Prices below are approximate and stated as of July 2026; always check Microsoft’s pricing page for the current figures, since they change.

Power BI Desktop is free. Building reports on your computer costs nothing.

Sharing through the Service is where licenses come in. There are three per-person levels and one organization-wide option.

Free. You can build reports and use your own My Workspace, but you cannot share with others or publish to team workspaces. Good for learning and personal use.
Pro. The standard working license. It lets you publish to shared workspaces, share, and collaborate. Roughly $14 per user per month, paid yearly, as of July 2026.
Premium Per User (PPU). Everything in Pro plus heavier-duty features (larger data models, more frequent refreshes, and more), but people you share PPU content with also need PPU. Roughly $24 per user per month, paid yearly, as of July 2026.
Capacity (Microsoft Fabric F SKUs). Instead of buying a license per person, an organization buys a pool of computing power for everyone. Its big advantage: at a large enough size (F64 or above), people with only a Free license can view content shared from that capacity, which saves money when hundreds of people just need to read dashboards. Capacity is priced at the organization level and starts in the low hundreds of dollars per month for the smallest size, climbing from there.

The short version for most beginners: Pro is the license you will most likely need to share your work, and your organization decides whether it also runs a shared capacity for wider, cheaper viewing.

Your capstone dashboard

Now you put it all together: the whole track in one project, built end to end with your own data.

Try It: The Capstone Project Pick one real, small dataset you care about. A team sales sheet, a budget tracker, a project list, an order log, anything with a few columns and enough rows to be interesting. Then run the full workflow.

1. Connect (Chapter 2). In Power BI Desktop, use Get Data to bring in your source. Do not clean it yet; just get it loaded.

2. Clean it in Power Query (Chapter 3). Open Power Query Editor. Remove junk columns, fix data types, filter out blank or broken rows, rename columns to plain names. Aim for a tidy table you would be happy to hand a coworker.

3. Build the model (Chapter 4). If you have more than one table (say sales and a list of regions, or orders and a calendar), create the relationships between them so the tables work together. Even a simple two-table model counts.

4. Make clear visuals (Chapter 5). Add at least three visuals that answer a real question: totals by category, a trend over time, a card with one big number. Give them honest titles. Aim for clarity, not decoration.

5. Write one measure (Chapter 6). Create at least one DAX measure, for example Total Sales = SUM(Sales[Amount]), or a count, or an average, and put it in a visual. This is the moment your report starts calculating, not just displaying.

6. Add interactivity (Chapter 7). Add a slicer (a filter people click, like a year or a region) and confirm that clicking one visual filters the others. Your report should now respond to the person using it.

7. Publish and share (this chapter). Publish to a workspace. Open it in the Service, set up a scheduled refresh if your source supports it, and use Share to send it to one real person, or walk through the share dialog so you know exactly what you would be handing over.

When you finish, you will have carried one dataset the entire distance, from a raw file to a live, shareable dashboard. That is the whole skill.

Common pitfalls

Emailing the file instead of sharing the report. Attach a .pbix and hit send, and you have made a stale copy that will drift and multiply. Publish once, share the link, and everyone sees the same current version.

Oversharing by reflex. Making everyone a Member because it is quick is how the wrong person edits a report or exports data they should not see. Default to Viewer; give more only when someone truly needs it.

Forgetting to set up refresh. A published report is a snapshot until you schedule a refresh. Plenty of “live” dashboards are quietly frozen because nobody turned it on. Check that refresh is set, and that it is succeeding.

Missing the gateway for on-premises data. If your source lives on your company’s own servers and refresh keeps failing, the usual reason is that no gateway is installed to reach it. Raise it with IT; it is not a bug in your report.

Assuming the free license shares. People build something great, then find they cannot send it to anyone without a Pro license or a capacity behind it. Know which license you have before you promise a rollout.

Your move

Do the capstone with a dataset you genuinely use. A real file you care about will teach you far more than a throwaway sample.

Run all seven steps in order, from Get Data to Publish and Share. When you can carry a dataset the full distance on your own, without a tutorial open beside you, you have finished the track and you can genuinely say you know Power BI.

Before you call it done, hold your capstone against this checklist and answer each one honestly.

Self-assessment checklist

Check	Did you do it?
Connected real data	You pulled in a genuine source with Get Data, not a canned sample.
Cleaned it	You used Power Query to fix types, drop junk, and tidy the table.
Built a sensible model	Your tables have the right relationships (or you have one clean table that needs none).
Clear visuals	At least three visuals, each answering a real question, with honest titles.
At least one measure	You wrote a DAX measure and used it in a visual.
Interactivity works	A slicer or cross-filtering lets the user explore, and the visuals respond.
Published and shared	The report is in a workspace, refresh is considered, and you know exactly who can see it.
You can explain every number	For any figure on the dashboard, you can say where it came from and how it was calculated.

That last row is the real test. A dashboard you can explain, line by line, is one you can stand behind. That is what it means to own your work in Power BI.

Part of the Power BI track. Developed with AI assistance and reviewed by a human editor. Power BI changes often; menu names, features, and prices may have shifted since the “checked on” dates in this chapter. Verify anything critical against Microsoft’s official documentation.