Raushan had just completed his first interactive report. His bar charts, maps, and slicers were all looking amazing, and he felt pretty proud of himself. But there was one thing missing: he wanted to share this with his team. After all, what's the point of building beautiful reports if no one else can see them?
That's when Ritu came to the rescue again.
"Raushan, have you tried Power BI Service?" she asked.
"Power BI Service? What's that?" Raushan replied.
"It's where your reports can live in the cloud, be accessed by everyone on your team — and you control exactly who sees what data, based on their role."
- Publish = upload a .pbix from Desktop to Service with one click
- Workspace = a shared folder in Service where team reports live
- Dashboard = pins from multiple reports assembled into one view
- RLS = row-level security — configured in Desktop, applied in Service
🌐 Step 1 — Publish to Power BI Service
Raushan went back to Power BI Desktop. He clicked the Publish button on the Home ribbon and selected his team's workspace. In moments, his report was live in the cloud.
Once published, Raushan could:
- Share the report with teammates via a link
- Let his team comment directly on the report
- Set permissions — choosing who could view and who could edit
- Schedule automatic data refresh — no more manual refreshes in Desktop
"This is like handing my team a real-time version of my reports — not just static PDFs." — Raushan
🏢 Workspace Roles — Who Can Do What
When Raushan added his colleagues to the workspace, he had to assign each person a role. Power BI Service has four workspace roles:
| Role | Can Publish? | Can Edit? | Can View? | Use For |
|---|---|---|---|---|
| Admin | ✅ | ✅ | ✅ | Workspace owner — full control including adding/removing members |
| Member | ✅ | ✅ | ✅ | Senior report authors — can publish and share content |
| Contributor | ✅ | ✅ | ✅ | Report builders — can edit and publish but cannot share |
| Viewer | ❌ | ❌ | ✅ | Consumers only — can view and interact, cannot change anything |
🔑 Row-Level Security — One Report, Different Data per User
Raushan's company had managers, analysts, and field reps — each needed different levels of access to the same dataset:
- Managers — could see the full dataset across all regions
- Analysts — needed aggregate data and trends only
- Field Reps — could see only their own region's sales
Raushan set up Row-Level Security (RLS) — a DAX filter rule applied per role. The same report, the same visual — but each user sees only the rows their role allows. Configured in Desktop (Modelling → Manage Roles), enforced automatically in Service based on who is logged in.
📲 Dashboards — One View, Many Reports
Raushan clicked Pin to Dashboard on his key visuals — combining charts from his sales report, his logistics report, and his HR report into one central dashboard. His manager now had a single page showing all the KPIs she needed, each live-updating from its source report.
Report vs Dashboard — the key difference: A report comes from one dataset and has multiple pages for detailed analysis. A dashboard is a single page of pinned tiles from one or many reports — designed for at-a-glance monitoring, not deep exploration.
- Sharing from My Workspace. My Workspace is a personal sandbox — reports shared from there cannot be transferred to app workspaces, cannot be certified, and are lost if the owner's account is deactivated. Always build team reports in a dedicated shared workspace, not My Workspace.
- Publishing without configuring RLS. If you share a sales report before setting up RLS, every Field Rep can see every other region's numbers. That is a data governance failure. Always define and test RLS roles before sharing with your first stakeholder.
- Sharing a report without scheduling refresh. A published report connected to a local Excel file will never update on its own. Stakeholders will be looking at stale data from publish day. After publishing, go to the dataset settings in Service → Scheduled Refresh, and configure the gateway and schedule immediately.
- Power BI Desktop builds reports; Power BI Service hosts, shares, and governs them — you need both
- Workspace roles (Admin, Member, Contributor, Viewer) control access to all content in a workspace
- RLS adds a data-row filter per user role — configured in Desktop, enforced in Service automatically
- Dashboards pin tiles from multiple reports into one monitoring view — different from a multi-page report
- Always configure refresh schedule and RLS before sharing with your first stakeholder
📝 Try It Yourself — Share Your First Report in Power BI Service
-
Publish Your Report
In Power BI Desktop, click Publish and sign into your Power BI Service account. Upload your report to a workspace (not My Workspace). -
Set Up Row-Level Security
In Power BI Desktop, go to Modelling → Manage Roles and define a role with a DAX filter (e.g.,[Region] = USERPRINCIPALNAME()or a static filter). Publish again, then in Power BI Service assign a user to that role and verify they see only filtered data. -
Share Your Report
Open your report in Power BI Service and click Share to send a link to a colleague. Assign them Viewer role so they can see but not edit. -
Create a Dashboard
Pin visuals from your report to a new dashboard. Arrange the tiles for an at-a-glance executive view. -
Configure Scheduled Refresh
Go to the dataset in Service → Settings → Scheduled Refresh and configure a daily refresh. Confirm the gateway is connected if using an on-premises source.
Q1. Raushan wants his colleague to be able to view and interact with reports in a workspace, but not create, edit, or publish anything. Which workspace role should he assign?
Show Answer
Viewer. The Viewer role grants read-only access — the colleague can open, filter, and interact with reports but cannot modify, publish, or share any content in the workspace. This is the correct role for report consumers who are not report builders.
Q2. A field rep in the North region opens the sales report and sees data from all regions, not just North. RLS was supposedly configured. What are the two most likely causes?
Show Answer
Cause 1 — RLS was configured in Desktop but the user was not assigned to the role in Service. Defining a role in Power BI Desktop is only half the job. In Power BI Service, you must go to the dataset → Security and assign the specific user (or security group) to the role. Without this, the role is never applied.
Cause 2 — The user has Admin, Member, or Contributor access to the workspace. Users with edit access bypass RLS — they always see all data. RLS only applies to Viewer-role users assigned via the Security panel. If the field rep has Contributor access, RLS will not filter their view.
Q3. What is the key difference between a Power BI Report and a Power BI Dashboard, and when should you give your CEO a dashboard instead of a report?
Show Answer
Report: built from one dataset, has multiple pages, supports deep interactive analysis with cross-filtering, drill-through, and slicers.
Dashboard: a single page of pinned tiles from one or many reports and datasets — read-only, no cross-filtering between tiles, designed for monitoring KPIs at a glance.
Give your CEO a dashboard when they need a quick consolidated view of key metrics from multiple business areas without drilling into detail. Give them a report when they need to explore, filter, and analyse a specific domain in depth.
- RR Skillverse: Power BI Cheat Sheets →
- MS Learn: Roles in workspaces in Power BI →
- MS Learn: Implement row-level security (RLS) →