Ravindra BagaleCourses & study guides Track your progress

Chapter 38

38.1 Reports vs Dashboards, Sharing and Apps

Chala mitrano — today we stop calling every screen a dashboard. We pin, share, and publish Apps the way a real team does.

Fictional sample data for learning. All company names and brands belong to their owners. We use the names only so students can understand. Numbers on this page are made up.
After this lesson you can
  • Explain report vs dashboard in the Power BI Service.
  • Pin a tile and describe when a data alert helps.
  • Choose Share, workspace role, or App for a real case.
  • Outline how to create and update an App with audiences.
  • Refuse Publish to web for private company data.

Start with a problem (fictional). Neha Kulkarni (Pune) built a solid Blinkit-style MH sales report. She Shared the link with 12 people on WhatsApp. By Friday, three links were old, two managers still opened Desktop .pbix copies, and the CFO asked for one morning dashboard with an alert if Nashik orders fall. Neha needs App + dashboard discipline — not more links.

Sample layout — fictional data: report, dashboard, share paths and App
Sample layout — fictional data (not a real Service screenshot)

1. Report vs dashboard (Service meaning)

Why: Students mix the two words. In the Service they are different tools.

What: A report is multi-page interactive visuals on one semantic model. A dashboard is a single canvas of pinned tiles (often from many reports) plus optional alerts.

How — keep them straight:

Vertical steps (one under another)

  1. Open a report — many pages, slicers, drill-through.
  2. Pin a visual — it becomes a tile on a dashboard.
  3. Dashboards do not replace reports for deep analysis — they are the morning glance.

Tiny example: Neha Kulkarni in Pune pins GMV ₹18.6L (fictional) and Orders 1,240 to dashboard MH Morning. She still opens the full report when a city looks wrong.

Ravindra Bagale's Tip

Friends, in interviews say: report = explore; dashboard = glance + alert. Don't say they are the same.

2. Pinning tiles and alerts on dashboard tiles

Why: Managers want a beep when a KPI crosses a line — without opening Desktop.

What: You pin a tile, then set a data alert on card/KPI/gauge tiles (Import models).

How — set an alert (concept):

Vertical steps (one under another)

  1. Open the report visual — Pin visual — choose or create a dashboard.
  2. On the dashboard tile — ellipsis — Manage alerts.
  3. Set a threshold, e.g. Orders below 300 (fictional) — email Neha.
  4. Remember: alerts need refresh; stale Import = silent tile.

Tiny example: When Nashik fictional orders drop under 300, Neha gets mail at about 07:15 IST after refresh — she calls Raja Patil before standup.

Ravindra Bagale's Tip

Friends, alerts are not magic SMS for every DirectQuery case — check what your tenant allows. Prefer Import for simple threshold alerts in training.

3. Share link vs workspace access vs App

Why: Five friends and five hundred readers need different doors.

What: Three doors: Share on a report/dashboard, Access on the workspace, or an organisational App.

How — choose in 20 seconds:

Vertical steps (one under another)

  1. Only a few named reviewers? — Share (or temporary Viewer).
  2. Team that builds and tests? — workspace roles (ch 37).
  3. Whole org / many city managers? — App with audiences.

Tiny example: Carlos Mendes in Lisbon (fictional EU ops) gets a Share link for one week. 40 MH city managers get the App — not 40 Share links.

Ravindra Bagale's Tip

Friends, Apps scale. Share links litter. If you cannot list who still has access, you already lost governance.

WayBest forWatch out
Share link1-5 named people, quick reviewHard to audit months later
Workspace roleBuilders + a few ViewersDon't dump 500 people as Viewer here — use App
App50-500+ readers, clean updateNeeds Member/Admin to publish; audiences help

About this data: This table uses columns: Way, Best for, Watch out. This table uses columns: City, Orders, GMV INR. This table uses columns: Wrong, Better. Values shown are the lesson examples already on this page (not a new dataset).

4. Building and updating an App with audiences

Why: One publish should update everyone without emailing a new link each Monday.

What: An App packages selected workspace content. Audiences can show different navigation to different groups.

How — publish an App (concept steps):

Vertical steps (one under another)

  1. In the workspace — Create app (or Update app).
  2. Include the report (and dashboard if needed); set navigation names clearly.
  3. Add audience MH City Managers and audience Finance Read if views differ.
  4. Publish / Update. Tell users the App name — not a raw workspace URL.
  5. Next week: change report — Update app so everyone sees the new version.

Tiny example: Priya updates App Sales MH Live after fixing a typo. Raja opens the same App icon — no new email attachment.

Ravindra Bagale's Tip

Friends, put the App URL in Teams, not twenty personal Share links. Update app is your Monday habit.

5. Org sharing rules and free-user viewers on capacity

Why: Licence and tenant settings decide who can open shared content.

What: Pro/PPU/capacity rules vary. Free users may view content on Premium/Fabric capacity when admins allow. Always check your org policy — this page teaches the idea, not your contract.

How — ask before you promise:

Vertical steps (one under another)

  1. Confirm whether viewers need Pro or can use free + capacity.
  2. Check external guest sharing is allowed before inviting a vendor.
  3. Document the answer in your runbook (one line is enough).

Tiny example: Fictional training org: city managers on free + capacity; builders on Pro. Interview answer: It depends on capacity and tenant settings.

6. When not to use Publish to web

Why: Publish to web creates a public HTML link. Anyone with the URL can open it — no company login.

What: It is for public data only (marketing demos, open stats). Never for salaries, patients, NPA, or customer lists.

How — refuse safely:

Vertical steps (one under another)

  1. If a manager asks for just a public link, explain the risk in one sentence.
  2. Offer App, Share, or secure embed instead.
  3. Admins can disable Publish to web tenant-wide — good practice.

Tiny example: Sofia Müller (Munich, fictional) rejects Publish to web for euro demand plans. She publishes an App to the EU-IN workspace audience instead.

Ravindra Bagale's Tip

Friends, if data would hurt someone when leaked, Publish to web is wrong. Full stop.

7. Worked example — three industries

All numbers are fictional sample data.

Quick commerce (Maharashtra)

Why: 40 city managers need one App, not 40 Share links.

  1. Publish report to Sales MH.
  2. Pin GMV and Orders to dashboard MH Morning.
  3. Create App Sales MH Live with audience MH City Managers.
  4. Alert: Orders below 300 emails Neha.
CityOrdersGMV INR
Pune1,24018,60,000
Nashik4103,40,000
Kolhapur2802,10,000

Hospital network (fictional care group)

Dr. Amina Yusuf in Nairobi only needs bed occupancy glance on a dashboard tile. Clinical detail stays in a report App for ward leads — never Publish to web.

SaaS billing (Singapore)

Mei Lin pins MRR S$2.4M (fictional) to an exec dashboard; CSMs use the App for cohort pages.

Recap. Report explores. Dashboard glances and alerts. Share for few, workspace for builders, App for many. Never Publish to web private data.

Common mistakes

WrongBetter
Calling every canvas a dashboardUse Service words: report vs dashboard
500 Viewers in the workspaceApp + audiences
Publish to web for HR dataApp / Share / secure embed
Never updating the App after republishUpdate app every release

Quiz (5 questions)

1. In the Power BI Service, a dashboard is best described as:

2. You need 200 city managers to see the same live report. Best approach?

3. Publish to web is safe for:

4. After you change a report used by an App, you should:

5. Data alerts on tiles typically need:

Practice tasks (12) — hints only, no full answers

  1. Task. Write one sentence distinguishing report vs dashboard in the Service.
    Hint: explore vs glance.
  2. Task. List three tiles you would pin for a Mumbai hotel occupancy morning view (fictional).
    Hint: occupancy %, ADR, RevPAR style KPIs.
  3. Task. When would you use Share instead of an App?
    Hint: few named people, short review.
  4. Task. Name two audiences for an App covering MH sales and Finance.
    Hint: section 4.
  5. Task. Explain why Publish to web is wrong for patient bed lists.
    Hint: public URL.
  6. Task. Draft the alert threshold text for Nashik orders (fictional).
    Hint: below 300 example.
  7. Task. Interview 45s: how do you share with 500 readers?
    Hint: App + capacity/licence note.
  8. Task. What happens if you republish a report but never Update app?
    Hint: readers may stay on old package.
  9. Task. Compare workspace Viewer vs App audience in a two-column table of your own.
    Hint: builders room vs readers storefront.
  10. Task. Find three risks of WhatsApp-sharing report URLs.
    Hint: stale links, no audit, wrong version.
  11. Task. Mei Lin in Singapore needs MRR glance + alert. Report or dashboard first?
    Hint: pin to dashboard.
  12. Task. Write the one-line refusal when asked for Publish to web on HR data.
    Hint: section 6.

Ravi Sir's cards (Excel card style)

Standalone cards — no tip or photo sections. QR points to this lesson. Download PNG to revise offline.

Interview Card: Report vs dashboard vs App — what do you say in an interview?
Download interview-card PNG
Comparison Card: Share link vs workspace access vs App
Download comparison-card PNG
Revision Card: App publish checklist (Service)
Download revision-card PNG

Think like a professional

In a real tenant, rights and sharing are controlled by Fabric / Power BI admins. Always follow your company policy. This lesson uses fictional people and numbers so you can practise the ideas safely.