Power BI turns data into visuals, insights and shared understanding.

Business intelligence in plain words

Business intelligence, or BI, is the practice of collecting data from many places and presenting it so that people can make better decisions. Power BI is Microsoft’s BI product. You connect it to data sources, shape and combine the data, build a model with calculations, and create reports with charts, tables and maps. You then publish those reports to a cloud service where colleagues can view them in a browser, in a mobile app, inside Microsoft Teams, or embedded in other applications.

It is popular because it serves several kinds of people at once. Business users explore reports with a few clicks. Analysts build reports and models with a desktop tool. Data engineers prepare the data underneath. Administrators control who sees what. Developers embed analytics inside their own applications. All of them share one platform.

Why “in Azure”

The Power BI service is a cloud service that runs on Microsoft Azure infrastructure. Your organization’s tenant, which is its private space in Microsoft’s cloud, has a home region where the service stores your content. Power BI also works closely with many Azure data services such as Azure SQL Database, Azure Synapse Analytics, Azure Data Lake Storage, Azure Databricks and Azure Cosmos DB, and relies on Microsoft Entra ID, Azure’s identity service, for sign-in and permissions. So when people say “Power BI in Azure”, they usually mean three things together: the Power BI service hosted on Azure, the Azure data sources it reads, and the Azure features it uses for security, networking and operations.

Power BI is now part of a larger analytics platform, and this changes licensing and features.

Microsoft Fabric is a unified analytics platform that brings together data engineering, data warehousing, real-time analytics, data science and Power BI under one roof, with a shared storage layer called OneLake. Power BI is one of the experiences inside Fabric. Many capabilities that once required separate Azure services can now be done in Fabric, and some Power BI licensing has moved toward Fabric capacity-based models.

Two ways to run a modern solution

Organizations take one of two broad paths. In the first, they keep using separate Azure data services such as Synapse or Databricks for preparation, and use Power BI mainly for the reporting layer. In the second, they adopt Fabric more broadly so that data preparation, storage and reporting all live in one integrated platform. Both paths are legitimate. Many organizations mix them during a gradual transition.

A handful of objects appear in every Power BI solution.

flowchart LR
  A["Data sources"] --> B["Dataflow or data preparation"]
  B --> C["Semantic model"]
  C --> D["Reports"]
  D --> E["Dashboards"]
  D --> F["App for wide audience"]
  C --> G["Other reports using the same model"]
        

Different tools serve different parts of the journey.

Languages inside the tools

Two languages power most of the work. Power Query, with its formula language called M, is used to connect to data and shape it: removing columns, merging tables, changing data types, and unpivoting. DAX, short for Data Analysis Expressions, is used to create calculations in the model: totals, ratios, running totals, year-over-year comparisons and measures that respond to the filters a user chooses. Learning to think in these two languages is the main step from casual user to capable analyst.

Understanding the moving parts helps you reason about speed, security and cost.

When a user opens a report in a browser, a chain of Azure components answers. The request authenticates with Microsoft Entra ID. The service checks permissions. The query engine runs the report’s questions against the semantic model, either from data held in memory or by sending queries to a source system. Results return to the browser, which draws the visuals. Where the model is hosted and how much compute it can use depends on the capacity attached to the workspace.

flowchart TD
  U["User in browser, Teams or mobile"] --> E["Microsoft Entra ID sign-in"]
  E --> S["Power BI service in tenant home region"]
  S --> C["Capacity: compute for queries and refresh"]
  C --> M["Semantic model in memory"]
  C -.->|DirectQuery or refresh| D["Azure data sources"]
  C -.->|Through gateway| G["On-premises or private network sources"]
        

Tenant, home region and data location

Your organization’s tenant has a home region, which is where Power BI stores its tenant metadata and, by default, your content. Large organizations with data residency rules can use multi-geo capabilities to place certain content in other regions, so that data for a particular country stays in that country. Because these rules matter legally, confirm the current options with your administrator and documentation.

Shared capacity versus dedicated capacity

With the basic per-user licensing, content lives on shared capacity, where compute is pooled among many customers and managed by Microsoft. With a dedicated capacity, you purchase a reserved amount of compute that serves only your organization. Dedicated capacity offers more predictable performance, larger model sizes, more frequent refresh, advanced features and, at larger sizes, the ability for free-licensed viewers to read content.

Power BI has connectors for a large catalog of sources, and Azure services are first-class citizens.

flowchart LR
  A["Azure SQL"] --> P["Power BI semantic model"]
  B["Synapse"] --> P
  C["Data Lake Storage"] --> P
  D["Databricks"] --> P
  E["Cosmos DB"] --> P
  F["Fabric lakehouse"] --> P
  G["Excel, files, SaaS applications"] --> P
  P --> R["Reports and dashboards"]
        

Authentication to the source

The model must prove who it is to each data source. Options include a stored credential, an organizational account that signs in with Entra ID, and, for supported sources, single sign-on, where the actual report viewer’s identity is passed through so that the source can apply its own per-user security. Single sign-on is powerful but needs careful setup, and it works with direct query connections rather than imported data.

The most important design decision in Power BI is where the data lives at query time.

A storage mode describes how a table in the model gets its data when users interact with a report. Each mode trades freshness, speed, size and cost.

flowchart TD
  A["Choose a storage mode"] --> B{"Need data fresher than a scheduled refresh?"}
  B -->|No| C{"Data fits within model size limits?"}
  C -->|Yes| D["Import"]
  C -->|No| E["Consider Direct Lake, aggregations or composite model"]
  B -->|Yes| F{"Data in a Fabric lakehouse or warehouse?"}
  F -->|Yes| G["Direct Lake"]
  F -->|No| H["DirectQuery against a well-tuned source"]
        

A clean model makes reports fast, accurate and easy to build; a messy one makes everything harder.

The star schema

The widely recommended design is the star schema. In the middle sits a fact table, which holds the events or measurements you want to analyze, such as sales lines, with numeric values and keys. Around it sit dimension tables, which describe the context: customers, products, dates, stores. Each dimension connects to the fact table through a relationship. The shape looks like a star, which gives it its name. This structure matches the way the engine is optimized and keeps calculations simple.

flowchart TD
  F["Fact table: Sales"]
  D1["Dimension: Date"] --> F
  D2["Dimension: Product"] --> F
  D3["Dimension: Customer"] --> F
  D4["Dimension: Store"] --> F
        

Measures versus columns

A calculated column stores a computed value for every row and uses memory. A measure is a calculation evaluated at query time, in the context of whatever filters the user has applied. Totals, averages, ratios and comparisons are best written as measures. Because measures respond to filters, one measure can answer questions about any product, region or period without being rewritten.

Filter context

The key concept in DAX is filter context: the set of filters in effect when a calculation runs. Clicking a region, choosing a month and placing products in rows all contribute to the context. A measure like “total sales” gives different answers in each cell of a table because each cell has a different context. Understanding this, and how functions can modify the context, is the heart of DAX.

Cloud services cannot reach inside your private network unless you give them a safe door.

If your data lives on a server inside your own data center, or inside an Azure virtual network that is not publicly reachable, the Power BI service cannot connect directly. A gateway solves this. It is a small piece of software that runs inside your network and makes only outbound connections to the cloud. When the service needs data, it sends a request through the cloud relay, the gateway runs the query against the private source and returns the results.

sequenceDiagram
  participant PBI as Power BI service
  participant R as Cloud relay
  participant G as Gateway in private network
  participant S as Private data source
  G->>R: Outbound connection kept open
  PBI->>R: Request for data refresh
  R->>G: Forward request
  G->>S: Run query
  S-->>G: Data
  G-->>PBI: Results sent back securely
        

Operating a gateway well

Treat the gateway like a production server. Run it on a dedicated, well-sized machine close to the data source, not on someone’s laptop. Install it on more than one machine to form a cluster for high availability. Keep the software updated. Monitor processor, memory and network use, because refreshes and DirectQuery traffic all pass through it. Document who owns it and how credentials are stored.

Imported data is a snapshot, so you must decide how it stays current.

Scheduled refresh

A refresh reloads data from the sources into the model. You can run it on a schedule, such as nightly or every hour, or trigger it through an API when upstream data is ready. The number of scheduled refreshes per day depends on the license and capacity, and larger dedicated capacities allow more frequent refreshes. Check the current limits for your plan.

Incremental refresh

Reloading years of history every night is wasteful. Incremental refresh divides a large table into time-based partitions and refreshes only the recent ones, such as the last few days, while keeping older partitions untouched. This makes refreshes much faster, reduces load on the source, and allows bigger tables. It requires the data to have a reliable date column and the source to support filtering by that date efficiently.

flowchart LR
  A["Partition: years ago"] --> B["Partition: last year, archived"]
  B --> C["Partition: recent months, refreshed rarely"]
  C --> D["Partition: last days, refreshed every time"]
  D --> E["Optional: real-time partition via DirectQuery"]
        

Query folding

Query folding is when Power Query translates your data shaping steps into a single query that the source runs itself, instead of pulling all rows and shaping them locally. When folding works, refresh is faster and gentler on the network. Certain operations break folding, and once broken, later steps run in the engine. Design transformations so that the heavy filtering and joining steps come first and fold to the source.

The licensing model decides who can build, who can view, and how much power you get.

Pausing and scaling in Azure

Because capacities are Azure resources, you can often scale them up and down and, for some types, pause them when not in use. Pausing stops the compute charge but also makes content on that capacity unavailable until resumed. This is useful for development or embedded scenarios with predictable idle periods, but it must be planned so that users are not surprised.

Different people should see different data, and every layer of the platform helps enforce that.

Identity with Microsoft Entra ID

Users sign in with Microsoft Entra ID. This brings centralized controls: multi-factor authentication, conditional access rules that require compliant devices or trusted locations, and group-based assignment of permissions. Always manage access through groups instead of individual users so that onboarding and offboarding are simple.

Workspace roles

Row-level security

Row-level security, or RLS, restricts which rows of data each user may see. You define roles in the semantic model with filter rules, then assign users or groups to those roles. A regional manager sees only their region’s rows, even though everyone uses the same report. A more flexible technique, dynamic RLS, uses a table that maps each user’s sign-in name to the data they are allowed to see, so rules are maintained as data instead of as many separate roles.

flowchart LR
  U1["Manager A"] --> R["One report, one model"]
  U2["Manager B"] --> R
  R --> F["RLS filter applied by sign-in identity"]
  F --> D1["Rows for region A"]
  F --> D2["Rows for region B"]
        

More layers of protection

For regulated organizations, the path of the traffic matters as much as the permissions.

By default, users reach the Power BI service over the public internet, authenticated and encrypted. Many organizations want more control. Azure Private Link, available for Power BI at the tenant level and, in newer offerings, at the workspace level, lets you route access to the service through a private endpoint in your own virtual network. You can then block public internet access to Power BI, so that only traffic from your network, including on-premises connected through private links, can use it.

flowchart LR
  A["Corporate network and VPN"] --> B["Private endpoint in your virtual network"]
  B --> C["Power BI service over Microsoft backbone"]
  D["Public internet"] -.->|Blocked when public access is disabled| C
        

Self-service is powerful, and without guardrails it becomes chaos.

Power BI makes it easy for anyone to create reports, which is a strength and a risk. Without governance, organizations end up with thousands of overlapping reports, conflicting numbers, orphaned content and accidental exposure of sensitive data. Governance means setting clear rules and tools so that freedom and trust coexist.

A workable operating model

Reports are software. Treat changes with the discipline software deserves.

Development, test and production

Editing a live report that executives rely on is risky. Deployment pipelines give you separate stages, typically development, test and production, each tied to a workspace. Authors build in development, testers review in the test stage, and approved content is promoted to production. Rules can change data source connections and parameters per stage, so that the test version reads from test data and the production version from production data.

flowchart LR
  A["Development workspace"] -->|Promote| B["Test workspace"]
  B -->|Review and approve| C["Production workspace"]
  C --> D["Users via app"]
  A -.-> G["Git repository"]
        

Slow reports lose users. Most slowness has a few common causes.

A report is slow because of one of three things: the visuals ask for too much, the DAX is inefficient, or the model or source is poorly designed. Find which before tuning anything.

Operate the platform with data, not guesses.

Understanding capacity pressure

A capacity has a fixed amount of compute per time period. Interactive queries and background refreshes both draw from it. When demand exceeds supply, the capacity can borrow against future time for a while and then may delay or throttle work. The effect is slow reports and delayed refreshes. The usual remedies are to spread refresh schedules so that they do not all start at the top of the hour, to optimize the heaviest models, to move non-critical work to another capacity, or to scale up.

Put reports inside your own applications so users never leave them.

Power BI content can be embedded in websites and applications. There are two main models, and the choice drives licensing, identity and architecture.

sequenceDiagram
  participant C as Customer in your app
  participant A as Your application backend
  participant E as Microsoft Entra ID
  participant P as Power BI service
  C->>A: Open analytics page
  A->>E: Authenticate with service identity
  E-->>A: Access token
  A->>P: Request embed token with row-level identity
  P-->>A: Embed token
  A-->>C: Page with embedded report and token
  C->>P: Report loads using embed token
        

Design considerations

Power BI is the visible layer; Azure provides the engine room.

flowchart LR
  A["Operational systems"] --> B["Ingestion: Data Factory or Fabric pipelines"]
  B --> C["Data lake storage"]
  C --> D["Transformation: Synapse, Databricks or Fabric"]
  D --> E["Warehouse or lakehouse"]
  E --> F["Power BI semantic model"]
  F --> G["Reports, apps and embedded analytics"]
  H["Catalog and governance"] -.-> C
  H -.-> F
        

The medallion idea

Many lake-based architectures organize data into layers: a raw layer that stores data exactly as received, a cleaned layer where errors are fixed and formats standardized, and a curated layer shaped for analysis. Power BI models should sit on the curated layer. If analysts must do heavy cleaning in Power Query, it signals that the upstream curation is incomplete.

Smart assistance and AI features

Power BI includes AI-assisted features such as natural language questions, automated insights and a conversational assistant that can help create reports and explain data. Availability depends on license, capacity and tenant settings and changes often, so confirm what is available to you. Whatever the tool, remember that AI answers are only as good as the model’s definitions, descriptions and security. A clean, well-documented model is the best preparation for any AI feature.

The bill depends on licenses, capacity, data sources and people.

Costs come from several places. There are license costs for users who build and share. There is capacity cost for dedicated compute. There is the cost of the underlying data services such as warehouses, storage, and data movement. Then there is the cost of people’s time maintaining content. Optimizing means keeping each in proportion to the value delivered.

Habits that scale, and habits that hurt.

Patterns worth adopting

Anti-patterns to avoid

A review list before you launch or audit a solution.

How organizations put the pieces together.

Short answers to common beginner questions.

The Power BI service runs on Azure infrastructure and relies on Azure identity and many Azure data services, but it is licensed and administered as its own Microsoft product, which is now also a part of Microsoft Fabric.

Desktop is the application on your computer where you connect to data, build the model and design reports. The service is the cloud where you publish, share, schedule refresh, secure and collaborate.

Start with Import because it is the fastest and most capable. Use DirectQuery or Direct Lake only when you need data fresher than scheduled refresh allows or the data is too big for import, and plan for source performance.

Only if the service cannot reach your data source directly, such as a server in your data center or a source locked inside a private virtual network. Publicly reachable Azure sources typically do not need one.

It is the data model behind reports: tables, relationships and calculations. It was previously called a dataset. Many reports can share one model.

You define roles with filters in the model and assign users or groups to them. When a user opens a report, the filters limit the rows they can see. Users with edit rights on the model can bypass the restrictions, so assign roles carefully.

A capacity is a reserved pool of compute purchased for your organization. You may need one if you have many viewers, large models, frequent refresh or advanced features, or if you embed analytics for customers.

Common causes include too many visuals, inefficient calculations, a poor model design, a slow DirectQuery source, or an overloaded capacity. Measure with the performance analysis tools before changing anything.

It depends on your license and capacity. Dedicated capacities allow more frequent refreshes than shared ones, and DirectQuery or Direct Lake can provide fresher data without scheduled refresh. Check the current limits for your plan.

Yes, using Azure Private Link for Power BI, combined with conditional access and private data gateways. Plan DNS and exceptions carefully and confirm the current limitations.

Use deployment pipelines with separate workspaces, parameters for data sources, and source control, so changes are reviewed and promoted instead of being edited live.

Yes. You can embed for your own employees, who sign in with their identities, or for customers, using a service identity and server-generated tokens, usually on a capacity purchased in Azure.

No. License names, capacity sizes, prices, viewing thresholds and available features change over time, especially with the evolution of Microsoft Fabric. Always confirm with the current official documentation before planning or buying.

Power BI in Azure combines a cloud analytics service, a rich ecosystem of Azure data sources and Azure’s identity, networking and governance features. A successful solution starts with clean, well-shaped data and a star-schema semantic model, chooses the right storage mode, refreshes efficiently, and shares a small set of certified models for many reports. It protects data through groups, row-level security, sensitivity labels and, where needed, private connectivity. It treats reports as software with pipelines and source control, watches capacity and refresh health, and keeps costs aligned with usage. Because the product and its licensing keep evolving alongside Microsoft Fabric, the wise habit is to hold on to the stable ideas in this guide and verify the details in current documentation. With those habits, your organization can move from mountains of numbers to clear, trusted answers.