24. Reports and Dashboards

24.1 Report vs Dashboard

By Ravindra Bagale · Last updated: 6 October 2026

Quick answer: the short, self-contained version of this lesson is the guide Power BI Dashboard vs Report.

First look at the data (before → after):

Service › open report › hover a visual › Pin visual (pin icon)
Pin to: New dashboard "State Head" › Pin

People often say "dashboard" for any Power BI page. In Power BI, the two words mean different things.

Why a report is not a Service dashboard

Students mix the words because, in ordinary speech, any page of numbers is "a dashboard". In this product the words are two tools, and the business does not get the same thing from them.

A report is the file you build, usually in Desktop, with pages, a model, slicers, cross-filtering, and drill. Publishing it to a workspace does not turn it into a dashboard. It is still a report, sitting in a workspace, with the same four pages. If the meeting invite says "dashboard" and the link opens that report, you have a naming problem, not a second product.

A dashboard in the Service is a new canvas. You create it by pinning. Each tile is a visual that left a report and landed on one screen. Tiles can come from more than one report. That is the main point. Rani can see an operations card and, later, a finance card, without opening either file. Clicking a tile does not filter its neighbours. It opens the report the tile came from. This is not a bug. It is how dashboards are designed to work. People who need tiles to filter each other do not need a dashboard. They need the report.

A pinned live page is the exception that confuses everyone. The page stays interactive, slicers and all, inside a tile. You did not suddenly get cross-filtering across the dashboard. You embedded one report page. Say that when you demo it, or the room will think the product changed its mind.

What you get from the report:

• A question that can change shape. Shraddha selects nothing, because RLS already holds her to Nashik, and she still drills from city to store to order.
• Comparisons that react. Click Gangapur and the other stores dim, if you left that interaction on.
• Room for the second and third question, on later pages, without stuffing Monday's screen.
• One model, so % under 10 minutes means the same thing on every page.

What you do not get from the report alone:

• A single screen that mixes tiles from the operations report and a finance report.
• A data alert on a card that finds Rani when she is not looking at the file.
• A cockpit that is safe to open for ten seconds between two calls. A four-page report invites wandering.

What you get from the Service dashboard:

• One canvas for the numbers that are allowed to leave the report.
• Alerts on card, KPI, and gauge tiles, checked when the data refreshes.
• A phone layout that is not "the report, squeezed".
• A place in an app, next to the report, for people who should see the cockpit and not the model.

What you do not get from the dashboard:

• The store name, unless you pinned a visual that already shows it.
• A slicer that changes every tile together.
• Forgiveness if you pinned the wrong number. A tile of total orders will be read as the point of the business, every morning, until someone deletes it.

Who opens which on Monday

Use the same fictional week as section 23.7 so the faces match the numbers. 32 of 40 delivered orders are inside 10 minutes (80%). 5 of 50 orders are cancelled (10%). AOV is ₹16,000 ÷ 40 = ₹400. Pune is 15 of 19 (about 79%). Nashik is 17 of 21 (about 81%). Kothrud is 3 of 6 (50%). Gangapur is 4 of 6 (66.7%).

Rani opens the dashboard first. Around 7:50 IST, on a phone, between calls. She is not going to slice. She needs to know whether the state is inside the promise or whether she must tap. The cockpit shows the 80%, the 10% cancels, the AOV, and the two city tiles. Orders, if they are pinned at all, are labelled context. The cities look close. That is not a reason to close the phone. It is a reason to tap, because she has already learned, from the drill in section 23.8, that 79% can hide Kothrud. The tap opens the report. The Nashik tile does not become Nashik-only when she does it. She is in the report now. That handoff is what she gets.

Shraddha does not start on the cockpit. Her question is already a store. A Nashik tile at 81% would let her go back to sleep on Gangapur. She opens the report. RLS shows Nashik. The delivery page shows College Road at 90%, Satpur at 80%, Gangapur at 66.7%. The decision changes: Gangapur, not the city tile. She does not get an alert from this habit. If she only opens the report when she remembers, a bad hour can pass. That is why Rani's alert still matters. Different tool, different job.

Ravindra opens the report when the Pune tile is the one that needs a store, which in this week it does, even though 79% looks near Nashik. He needs Kothrud, not the tile. Baner, with 6 orders and a clean week, must not win a rider just because someone sorted the cockpit by orders.

A finance reader in the app should not land on this cockpit. Wages and the 10-minute promise are different Monday questions. The app audience exists so that person gets the finance report. Putting delivery tiles on their home teaches them that speed is a finance card, and it teaches Rani nothing about wages.

Someone who is still checking the measure — did cancels get into the sales total, is the denominator delivered orders — stays in the report, and in the model. A tile cannot show that argument. Pinning a number you have not tested just publishes the argument onto Rani's phone.

Sample layout — fictional data. Left: Shraddha's report, still able to show Gangapur. Right: Rani's cockpit. The tiles do not filter each other. Orders are on the canvas only as context. Kothrud is not visible until the report opens.

What goes wrong when the words are mixed

Three failures show up in real teams, and they are all avoidable.

1. The report is described as the dashboard, so nobody pins the decision KPI. The file has the right measure, on page two, where Shraddha can find it. Rani's phone still shows whatever was easy to pin. Often that is total orders, because the card already existed. The business then manages the vanity metric in the only place the boss looks.

2. A tile is pinned with a slicer still on. Section 24.4 warns you. Here is the business version. Someone pinned "orders by city" while Platform was Blinkit, and the subtitle is easy to miss on a phone. Rani thinks she is looking at Maharashtra. She is looking at one platform. She may move a rider in Pune for a gap that the other platform does not have, or the reverse. Re-pin from the state you are willing to defend out loud.

3. Everyone is sent the dashboard "so they see the same thing". They do not see the same thing they need. Shraddha sees a city. She needed a store. The analyst sees a frozen tile. They needed to change a filter. Sameness is not usefulness. The app can hold both objects. Use it.

Interview answer, short enough to say: a report is the multi-page interactive analysis on one model; a Service dashboard is one canvas of pinned tiles, possibly from many reports, and a click opens the source instead of filtering the canvas. Then give the Monday: Rani taps, Shraddha drills. If you only define the menus, you have described the product and not the job.

Fix common mistakes

Practise independently

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards