From Business Question to Power BI Report: PL-300 Scenarios

A request for “a sales dashboard” is not yet an analytical requirement. It tells the analyst neither what decision the business must make nor what a convincing answer would look like. Two departments can use the same sales data to ask incompatible questions: finance wants audited revenue by accounting period, sales wants pipeline movement by opportunity stage, and operations wants orders that missed their promised delivery dates. A report built before those definitions are settled may appear sophisticated while explaining the wrong phenomenon.

This is a useful way to approach Microsoft PL-300. The Power BI Data Analyst role is about turning available data into actionable insight, not simply placing fields onto visuals. The April 2026 Microsoft outline spans preparation, modeling, visual analysis, and governance, with substantial weighting across each. Business scenarios pull those topics together: an analytical decision is only as sound as its source data, measure definitions, report interactions, and access model.

Translate an executive request into a measurable decision

Suppose a retail executive asks, “Why did our sales fall in the north?” Before writing a DAX measure, determine what “sales” means. Is the company discussing recognized revenue, submitted orders, shipped value, or invoiced amounts? Does “north” refer to a customer’s current territory or the salesperson assigned when the transaction occurred? Is the comparison against the previous month, the same month last year, the budget, or a rolling average? Different definitions can produce different answers without any arithmetic error.

An effective analytical brief names the decision, audience, time horizon, required grain, exclusions, data owner, and acceptable freshness. For this case the decision might be whether to adjust inventory allocations next quarter. The primary metric could be net invoiced revenue in a consistent local currency, compared with the same fiscal quarter last year. The report must distinguish price, volume, product mix, returns, and territory reassignment if those drivers exist in the underlying records. Ask stakeholders which of these can actually be measured rather than promising every possible explanation.

A business question also has a stopping rule. A senior leader may need three drivers and a link to exception detail; a financial analyst may need reconciliable transaction rows. Designing one enormous page for every audience frequently makes the experience worse for all of them. Choose a primary decision and provide drill paths when supporting analysis is justified.

Follow a metric from source record to headline KPI

Many reporting errors begin before Power BI is opened. Imagine a source system with an Orders table, an OrderLines table, a Customers table, and a Payments table. If a query joins Orders to OrderLines and then joins each line to several Payments, summing the result can multiply revenue. The report may show valid-looking numbers that are systematically inflated. The first job is to define each table’s grain and the keys that uniquely identify its records.

For an invoiced-sales report, the fact grain might be one invoice line. Dimensions could include Date, Product, Customer, and Geography, with attributes for grouping and filtering. A date table should align to the business calendar; a product hierarchy should reflect how the business interprets category-level movement. This is why star-schema modeling is so useful: it separates events from descriptive entities and makes filter routes easier to inspect.

The analyst should reconcile a known period total with the authoritative finance source before designing polished visuals. If the source says $4.8 million and the report shows $5.1 million, no choice of color palette will fix the trust problem. Investigate canceled documents, currency treatment, duplicate joins, returns, and the period used to recognize revenue. A dashboard becomes valuable only when someone can explain what its measures include and exclude.

Select measures that reflect the business definition

A total-sales measure can look as simple as SUM(Sales[NetAmount]), but whether it is correct depends on the underlying model. If NetAmount has already subtracted discounts and returns, the measure may be appropriate. If returns are stored in a separate fact table, subtracting them requires matching the reporting periods and business rules. Avoid using a catchy label for a measure whose logic no one has approved.

Ratios are particularly sensitive to context. Average order value is typically sales amount divided by order count, but the denominator might be distinct orders rather than rows in an order-line table. Gross margin percentage is margin divided by revenue, not the simple average of product-level margin percentages. A metric that appears correct on one card may fail when sliced by category, channel, or region. Check subtotals and filter behavior before showing it to stakeholders.

Time intelligence introduces another definition decision. A company using a fiscal year that begins in July needs comparisons mapped to that calendar. A partially completed month should not be presented as a full month without an explicit convention. A previous-year metric may require a comparable set of dates and careful treatment of leap days or incomplete periods. A candidate who can articulate these complications understands far more than a memorized DAX syntax pattern.

Choose visuals according to the judgment they support

A line chart is useful for a change over time, while a bar chart often works better for comparing discrete categories. A matrix may support finance reconciliation when the audience needs detailed cross-tabulation; it can be overwhelming on an executive home page. A card with a single number is only meaningful when its comparison, unit, and period are clear. If a revenue card says “12.4” without indicating whether that means millions of dollars or thousands of transactions, the report has failed at communication.

For the declining-sales example, a useful page could place the quarter-over-quarter variance beside its prior-year comparison, display a monthly trend, and show the product categories responsible for the change. A second page might decompose changes by volume and average selling price if the data supports that interpretation. Drillthrough can expose product or transaction details without forcing them into the first screen. The report should lead users from the question to the evidence in a coherent sequence.

Avoid treating every available visual feature as an improvement. Overused conditional formatting can make routine fluctuations look alarming. A dense scatterplot can communicate little when the axes and population are undefined. AI-generated narratives may help summarize data but still require an analyst to validate the metric definitions and causal claims. A confident sentence about “why” something happened is not justified by correlation alone.

Make filtering and navigation predictable

Slicers can make a report interactive, but their behavior must be designed. If a user selects the north region on the overview and drills into a customer page, should that filter persist? If a category chart highlights a selection, should the financial KPI show the selected category or the overall company total? These choices are business semantics, not mere formatting. A user who believes a KPI is filtered when it is not may make an incorrect decision even though each isolated calculation is technically valid.

Use bookmarks and navigation buttons only when the resulting state is clear. Explain the difference between a drillthrough that carries filter context and a page navigation action that simply changes pages. Where there are synchronized slicers, show enough feedback that the user can understand which filters remain active. Testing must include clearing slicers, selecting multiple values, drilling to detail, and returning to a summary page without losing the intended view.

Accessibility improves analytical reliability. Meaningful labels, readable contrast, logical navigation, and alternatives to color-only status indicators ensure that more people can interpret the evidence. Mobile layout needs its own selection of priority visuals rather than a tiny copy of a desktop page. Report usability is part of the PL-300 visualization domain because an insight that cannot be understood is not operationally useful.

Connect publication and security to the audience

Publishing a report does not settle who should see its underlying data. An internal sales manager might be permitted to examine only the accounts assigned to a region. Row-level security can apply a model-level filter, but the analyst also needs to understand workspace roles, permission boundaries, semantic-model access, and distribution through apps or other methods. A person who can edit the model is not in the same security position as a report consumer.

Use a realistic verification exercise: create two regional user roles and test the report with the relevant role context. Compare regional totals with trusted source extracts. Confirm that drillthrough, detail tables, and exports behave as intended. Do not rely on hiding a page or visual as a security control; it does not replace access enforcement at the appropriate layer. Governance also includes ownership of shared metrics, scheduled refresh, and sensitivity labels where relevant.

In organizations with several teams producing similar reports, a governed shared semantic model can protect metric consistency. The purpose is not to prevent self-service analysis but to give it a reliable foundation. The analyst should be able to say who owns each definition, how it changes, and what users will see when a refresh or access rule fails.

Work through a complete business case instead of isolated features

Take a subscription business with a board-level question: “Are cancellations increasing among customers acquired through paid advertising?” The raw data includes signup records, advertising attribution, invoices, refunds, and cancellation events. Before building visuals, define cohort date, cancellation timing, revenue type, duplicate customer handling, and any privacy limitations. A monthly cancellation rate needs a denominator that reflects customers eligible to cancel, not a convenient count of invoices.

Now create a small semantic model at a consistent grain and produce two measures: active subscribers and cancellations in period. Build a trend chart and a channel-level comparison. Check whether channel attribution changes after signup and decide whether cohort analysis uses original or current channel. Test boundary cases such as customers who cancel and reactivate. Finally, restrict sensitive customer-level detail while allowing stakeholders to inspect aggregate movement. This scenario naturally exercises data preparation, model relationships, DAX, visualization, and governance together.

If the report shows higher cancellation among one advertising source, avoid declaring the advertising source the cause. Differences in customer tenure, plan type, and product mix might explain the pattern. The right report exposes useful hypotheses and makes their limitations visible. Good analysis tells decision-makers where to investigate next and how much confidence to place in the available evidence.

Prepare for PL-300 by defending your choices

When reviewing a practice scenario, write down the business requirement before looking at the answer options. Ask whether the main issue concerns correct data shape, model relationship, DAX aggregation, visual behavior, or permissions. Then explain why an alternative could be tempting but would violate the requirement. If a scenario asks for month-over-month trends with regional drillthrough, a large transaction table on the overview is probably not the most effective answer even if it displays all the required fields.

The existing PL-300 certification preparation material can provide general exam orientation, while a case-study approach teaches the reasoning behind a decision. After finishing a case, change one assumption: the source becomes DirectQuery, the fiscal year changes, or regional users must have restricted access. Revisit the solution rather than treating it as permanently correct.

The practical standard for a Power BI analyst is straightforward: the data must reconcile, the metrics must mean what people think they mean, the visuals must help someone decide, and the access model must protect the underlying information. Business scenarios make those responsibilities visible. That is why learning to defend the design is often more useful than learning to produce another attractive dashboard.