Power BI starter: publish, share, and trust

You publish a report on Friday. Monday, three people forward different links, one person edited a measure in a personal workspace copy, and Finance is still using last month’s PDF because “the live one feels risky.” Sharing is easy in Power BI. Trust is a separate product. This part is about the boring machinery that makes a good model and good measures survive contact with an organization: workspaces, roles, refresh, row-level security, and a launch checklist you can actually run.

This is Part 3 of Power BI starter. Part 1 built the star. Part 2 wrote measures that match the question. Here we put the dataset and report where people can find them without inventing shadow copies. For metric ownership habits beyond the tool, see Metrics that matter and Data stewardship. For quality mindset when refresh fails, the Data quality series still applies. Map: Learn.

What you’ll learn

• How workspaces, apps, and dataset versus report roles differ in practice
• What to decide before you click Publish
• How scheduled refresh and failure alerts protect trust
• When row-level security (RLS) is required and how to test it
• A worked launch checklist for a first shared sales report
• Common share-and-trust mistakes and a practice plan

Shared is not the same as trusted

People treat a Power BI link like a source of truth the moment it appears in a channel. That is flattering and dangerous. Trust needs:

• A known owner who can change definitions and answer “why did this move?”
• A known refresh so timestamps mean something
• A known audience so sensitive rows do not leak through curiosity
• A known place so people stop forking personal copies
• A known definition for the metrics on the landing page

If any of those are missing, the report can still be useful privately. It should not be the company’s default link yet.

Rule of thumb: Do not put a report in the official app until you can name the owner, the refresh schedule, the sensitivity level, and the one metric people will argue about first.

Workspaces, apps, and who can do what

A workspace is a collaborative container for datasets, reports, dashboards, and more. Roles typically include Admin, Member, Contributor, and Viewer (names and exact rights evolve with Microsoft’s docs, so check your tenant’s current table). In practice:

• Viewers consume. They should not be your entire governance plan, but they are the default for broad audiences when you use an app.
• Contributors / Members build and publish content. Keep this group small for official workspaces.
• Admins handle access, settings, and cleanup when someone leaves.

A Power BI app is a packaged experience you distribute to a broader audience from a workspace. Apps help you present a stable navigation while builders keep working in the workspace. Many teams overshare the workspace itself and wonder why experimental pages become “official.” Prefer: builders in the workspace, consumers in the app (when your license and process support apps).

Also separate dataset (semantic model) concerns from report concerns. Multiple reports can sit on one certified dataset. That is good when measures are centralized. It is painful when every report embeds its own private copy of conflicting logic. Aim for one owned model for a domain, many thin reports if needed.

Before you click Publish

Run this short preflight in Desktop:

• Model view: relationships look intentional, no surprise many-to-many.
• Measures: named, formatted, dictionary text box present.
• Hidden keys and junk columns removed from report view.
• Landing page answers one primary question in under ten seconds.
• “About this report” page: owner, grain, refresh expectation, known limitations.
• Sensitivity labels applied if your company uses them (follow your info-sec policy).
• File name and report name match how people will search six months from now.

Publish to the correct workspace on purpose. Publishing to “My workspace” trains you to email PBIX files later. Personal workspaces are for sandboxes, not official metrics.

Refresh: the quiet trust killer

Import models need a scheduled refresh (or an on-premises data gateway when sources are inside the network). Trust dies when the banner says “data is from last Tuesday” during a Monday ops meeting and nobody owns the failure.

Set expectations in the UI

Show last refresh time on the landing page (card or text driven by a measure or dataset metadata pattern your org supports). If you cannot automate it, put the schedule in plain language: “Refreshes daily by 7:00 local, weekdays.” People can plan around honesty. They cannot plan around silence.

Failure alerts and ownership

Configure refresh failure notifications to a real mailbox or channel that a human reads. A shared inbox that nobody checks is theater. Document who restarts refresh, who fixes credentials, and who tells stakeholders when numbers will be late. That is stewardship, not glamour.

Credentials and gateways

Service account credentials should not live only in one analyst’s head. When that person is on leave, the dataset goes stale and the company invents Excel again. Store runbooks next to the workspace description: source systems, gateway name, who can rotate secrets.

Row-level security when “everyone” is not everyone

Row-level security (RLS) filters rows by user identity or role. Use it when a single report should show different slices to different people (regional managers, account owners) without shipping twenty copies of the PBIX.

Basic pattern:

• Define roles in Desktop (for example RegionManager).
• Write a filter expression on a dimension, such as dim_customer[region] = USERPRINCIPALNAME() mapped through a permissions table, or a simpler static role filter for pilots.
• Publish, map users or groups to roles in the service.
• Test as role before you celebrate.

RLS is not a substitute for legal or compliance review when data is highly sensitive. It is also not automatic. Builders with high workspace rights may still see more than consumers. Know who bypasses RLS and keep that group tiny.

Worked example: launch checklist for Sales Performance v1

Scenario: you finished the Part 1 star and Part 2 measures. Stakeholders want a shared “Sales Performance” view for East and West managers, plus a leadership rollup.

Decisions to write down

Launch sequence

• Publish Desktop file to the official workspace (not My workspace).
• Configure dataset credentials and gateway if needed; run a manual refresh once.
• Validate the three sanity measures against a known extract or warehouse query.
• Map RLS roles; use “Test as role” for East and West sample users.
• Add workspace description + About page content mirrored in the team wiki.
• Create or update the app navigation: Landing, Trends, Customers, About.
• Share the app link (not a random orphan report URL) in the announcement.
• Schedule a 20-minute office hours for the first week; collect definition bugs.

Announcement template you can steal

Sales Performance v1 is live in the Sales Leadership app.

Use for: net revenue and orders by region and category.
Do not use for: returns-adjusted P&L (not in model yet).
Refreshes: weekdays by ~7:00. If stale, ping #analytics-ops.
Owner: Alex (backup Sam).
Feedback: one thread this week, then we batch changes on Tuesdays.

That message does more for trust than another gradient on the title page.

Certification, endorsement, and “official” labels

Many tenants support endorsing or certifying datasets. Use those labels only when a process backs them: review of measures, documented owner, refresh monitoring. A certified sticker on a weekend experiment teaches people to ignore stickers. If your company has no formal process yet, start with clear naming (Official workspace versus Sandbox) and human announcements before you lean on badges.

Versioning without chaos

Power BI is not git by default (deployment pipelines exist for more mature setups). Starter discipline:

• Keep the PBIX in a known library (SharePoint/Teams) or use deployment pipelines when available.
• Bump a visible version on the About page when measures change.
• Prefer additive changes during the first month; announce breaking definition changes.
• Retire old app navigations instead of leaving three “final” reports alive.

When someone asks for a one-off field, resist forking the entire model into a personal copy. Either add it properly or give them an export with an expiration date.

Common mistakes

• Publishing to My workspace and emailing links. Creates shadow IT inside the BI tool.
• No refresh owner. Stale data with a modern UI is still stale data.
• Workspace open to the whole company as Member. Experiments become production by accident.
• RLS untested. “We added roles” is not the same as “East cannot see West.”
• Silent metric changes. Net Revenue flips definition on Tuesday without a note.
• Ten report URLs, zero app. People bookmark the wrong page forever.
• No known limitations. Users invent uses the model cannot support, then blame analytics.

How to practice this week

• Day 1: Inventory every Power BI link your team uses. Mark each: sandbox, personal, or official. Be honest.
• Day 2: Write an About page for one report that lacks one. Include owner, refresh, grain, limitations.
• Day 3: Confirm scheduled refresh and failure alerts for that dataset. Fix credentials documentation.
• Day 4: If RLS applies, test as two roles and record screenshots of different totals.
• Day 5: Draft the announcement template for your next publish. Remove one obsolete report link from the team channel topic.

Series wrap

Power BI starter in three moves: model before visuals, measures that match the question, publish with trust machinery. The tool rewards speed. Organizations reward boring reliability. If you take only one habit from the series, take the sanity page and the About page. They catch more pain than a new custom visual ever will.

Quick recap

• Trust needs owner, refresh, audience, place, and definition, not only a share link.
• Builders in workspaces; consumers preferably via apps with stable navigation.
• Refresh failures need humans and runbooks, not hope.
• RLS must be tested as roles; high-privilege builders may bypass it.
• Announce limits and version changes; retire old links on purpose.

Sources

• Microsoft Learn: Workspaces in Power BI
• Microsoft Learn: Apps in Power BI
• Microsoft Learn: Configure scheduled refresh
• Microsoft Learn: Row-level security (RLS) with Power BI
• Microsoft Learn: Endorse your content

Merch on Etsy

Open store →

Dashboard to Excel Ceramic Coffee Mug View on Etsy → You're On Mute White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → Y Hat Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Y Pred Mouse Pad View on Etsy → Naive Bayes Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Bayesian Mouse Pad View on Etsy →