Search…

BI Strategy and Reporting

Business Intelligence Reporting: A Complete Guide

Business Intelligence Reporting: A Complete Guide

How data moves through Power BI and Fabric to become a report someone reads: ingestion, the semantic model, the report, the app, and distribution.

How data moves through Power BI and Fabric to become a report someone reads: ingestion, the semantic model, the report, the app, and distribution.

Written By: Sajagan Thirugnanam

Last Updated on September 23, 2026

Business intelligence reporting is the pipeline that turns data sitting in a source system into a report a person actually opens and reads. In Power BI and Microsoft Fabric, that pipeline has five stages: get the data in, model it, build the report, put it in a workspace and package it as an app, and distribute it so people see it without hunting for it.

This guide walks through each stage and what it looks like to build. It does not cover the types of reports a business produces (operational, strategic, financial, and so on) or how to write one; see our guides to report types and KPI reports for that. If you have not yet decided what to build or how the rollout should work, start with our guide to creating a BI strategy.

The five stages

  1. Ingestion. Pull data from a source system into a form Power BI can use.

  2. Semantic model. Define the tables, relationships, and measures the report will run on.

  3. Report. Build the pages and visuals a reader interacts with.

  4. Workspace and app. Publish the report and package it for an audience.

  5. Distribution. Get it in front of readers on a schedule, or notify them when something changes.

Stage 1: Ingestion

Power Query is the ingestion layer in Power BI Desktop. It connects to a source, applies a sequence of transformation steps, and loads the result into the model. Each step is recorded, so the same transformation runs again on every refresh instead of being redone by hand.

let
    Source = Sql.Database("sales-server.database.windows.net", "Sales"),
    Orders = Source{[Schema = "dbo", Item = "Orders"]}[Data],
    FilteredRows = Table.SelectRows(Orders, each [OrderDate] >= #date(2026, 1, 1)),
    ChangedType = Table.TransformColumnTypes(
        FilteredRows,
        {{"OrderDate", type date}, {"Amount", type number}}
    )
in
    ChangedType

For a report used by one person, a query like this inside the .pbix file is enough. Once several reports need the same cleaned-up source, move the transformation into a Dataflow Gen2 in Fabric, so it runs once and every report references the output instead of repeating the same Power Query steps. Our guide to Dataflows Gen2 vs notebooks covers when a dataflow is the right tool and when a notebook is better suited to the transformation.

Stage 2: The semantic model

The semantic model (Power BI called this a dataset before Microsoft renamed the term) is where tables get related to each other and where every calculation a report will use gets defined once, as a measure, instead of being rebuilt inside each visual.

Most models are shaped as a star schema: one or more fact tables holding transactions, connected to dimension tables holding the things you slice by, such as Date, Product, or Customer. Our guide to star schema vs snowflake schema covers why that shape performs better than a single wide table.

Measures are written in DAX and stored in the model, not in a spreadsheet formula bar:

Total Revenue = SUM('Sales'[Amount])

Revenue YoY % =
VAR CurrentRevenue = [Total Revenue]
VAR PriorYearRevenue =
    CALCULATE([Total Revenue], SAMEPERIODLASTYEAR('Date'[Date]))
RETURN
    DIVIDE(CurrentRevenue - PriorYearRevenue, PriorYearRevenue)

SAMEPERIODLASTYEAR only works once the Date table is marked as a date table in Power BI Desktop, with a continuous range of dates and no gaps. Our complete DAX guide covers measures, row context, and filter context in depth.

Stage 3: The report

The report is the set of pages built on top of the semantic model. Each visual on a page is bound to one or more measures and columns from the model, not to a separate copy of the data. Building the report is where layout, filters, and interactivity get decided, but the report itself contains no data of its own once it is live in the service; it queries the semantic model behind it every time a reader opens it or changes a filter.

Stage 4: Workspace and app

A workspace is where a report lives once it is published from Power BI Desktop. Everyone who touches the report, from the person building it to the person only viewing it, holds one of four roles in that workspace:

Role

Publish and edit content

Manage who has access

Delete the workspace

Admin

Yes

Yes

Yes

Member

Yes

Add members with a lower role; publish or unpublish the app

No

Contributor

Yes

No

No

Viewer

No, view and interact only

No

No

A workspace is not what a business reader opens. For that, the workspace gets packaged into an app: a curated collection of the reports and dashboards you choose, with its own navigation, published to one or more audiences. Creating or updating an app needs a Power BI Pro or Premium Per User (PPU) license. A reader with no Pro or PPU license can only view that app if the workspace behind it runs on a Premium capacity or an F64-or-larger Fabric capacity; otherwise every viewer needs their own paid license. Our guide to Power BI workspaces and apps and guide to workspace access roles cover both in more detail.

Stage 5: Distribution

A published app still requires the reader to go open it. Three mechanisms get content to a reader without that step, and each fits a different kind of report:

Method

What the reader gets

Set up on

Requires

Email subscription

A snapshot emailed on a schedule (hourly, daily, weekly, monthly, or after each data refresh)

A report or dashboard

Pro or PPU, or a paid capacity workspace

Data alert

A notification when a value crosses a threshold you set

A gauge, KPI, or card tile pinned to a dashboard

Pro license for tiles outside your own workspace

Goals (scorecard)

A tracked metric against a target, with a status indicator

A workspace

A semantic model with the metric already defined

Subscribing yourself to a report only needs access to it and a Pro, PPU, or paid-capacity workspace. Subscribing other people additionally needs the Contributor, Member, or Admin role in that workspace. A data alert only fires on numeric card, KPI, and gauge tiles, and only after the underlying data refreshes; it does not work on a static export. Power BI Goals lets you set a target for a metric and see its status at a glance without the reader comparing numbers by hand; our guide to KPI reports covers how a KPI report uses scorecards specifically.

Where the mechanics stop and the content starts

Everything above is the plumbing: how a number gets from a source system into a report someone can subscribe to. What goes into that report, and which of the five report types it should be, is a separate decision covered in our guide to report types. What BI reporting is for at the organizational level, before any of these five stages start, is covered in our guide to building a BI strategy.

FAQs

What is BI reporting?

BI reporting is the process of moving data from a source system through a semantic model into a report a reader can open, then getting that report to the reader on a schedule or as a notification, rather than a one-off export.

Do I need Power BI Premium to distribute reports to people without a Pro license?

Yes, for viewing an app without individual Pro or PPU licenses. The workspace behind the app needs to run on a Premium capacity or an F64-or-larger Fabric capacity. Below that, every viewer needs their own paid license.

What is the difference between a subscription and a data alert?

A subscription emails a snapshot of a report or dashboard on a fixed schedule, regardless of whether anything changed. A data alert only notifies you when a specific numeric value on a card, KPI, or gauge tile crosses a threshold you set, and only after the data behind it refreshes.

Sources

Related to BI Strategy and Reporting

Want Power BI expertise in-house?

Get in Touch With Us

Turn your team into Power BI pros and establish reliable, company-wide reporting.

Berlin, DE

powerbi@casewhen.co

Follow us on

© 2026 CaseWhen Consulting
© 2026 CaseWhen Consulting
© 2026 CaseWhen Consulting