Begin with the everyday problem of data nobody can read, then see how a business intelligence service solves it.

The problem

A manager asks, “How are sales doing this month compared with last month, by region?” In many companies the answer takes days. Someone exports data from a system, pastes it into a spreadsheet, fixes the columns, builds a chart and emails the file. By the time the answer arrives, the question has changed. Different people also build different spreadsheets and get different totals, so meetings turn into arguments about whose number is right.

What the service is

Power BI is a family of tools for business intelligence, which means collecting data, shaping it, analyzing it and presenting it so people can make decisions. It has three main faces. A free desktop application is where analysts connect to data, clean it, build a model and design report pages. An online service in the cloud is where reports are published, shared, refreshed on a schedule and viewed in a browser or on a phone. And an embedding capability lets software companies and internal developers place reports and charts inside their own applications. Together they let one person build something once and thousands of people use it.

Why “in Azure”

Power BI is a Microsoft cloud service that runs on the same global infrastructure as Azure and signs people in with the same identity system. It rarely works alone. The data it shows usually lives in Azure services such as SQL databases, data lakes, analytics warehouses and streaming pipelines. Azure also supplies the things around Power BI: private networking, key storage, monitoring, and the capacity that can be rented to run reports at larger scale. So designing Power BI well means designing the Azure pieces around it.

What you gain

Business intelligence has changed in stages. Understanding the stages explains why the tool is shaped the way it is.

The paper and spreadsheet era

The first reports were printed. A computer printed a long list of figures and a clerk added them by hand. Spreadsheets improved this by letting anyone sort, sum and chart numbers. But spreadsheets live on one person’s computer. Copies multiply, formulas break silently, and nobody can tell which file is the latest.

The data warehouse era

Companies then built data warehouses: large databases that gather data from many systems and organize it for questions. A specialist team built reports on top, and business users requested them. Reports were consistent and trustworthy but slow to change. A new question could take weeks to answer because it needed a ticket, a developer and a test cycle.

Self-service analytics

Self-service tools let business users explore data on their own, using visual drag-and-drop screens. This freed the specialists from endless report requests. But it brought a new risk: hundreds of private reports, each with its own logic, again producing mismatched numbers. Good modern practice mixes the two: specialists build trusted shared models and data stores, and business users build reports on top of them.

The cloud era

Cloud services removed the need to buy servers for analytics. Data could be stored in cheap lakes, processed in elastic engines and shown through online services. Power BI grew in this setting: a cloud service with a desktop companion, closely linked to the wider Azure data platform and, more recently, to a unified analytics platform that brings storage, engineering and reporting under one roof.

Each term below says what it is, why it exists, a picture from daily life and an example.

How the words fit together

Read it as a chain: data is pulled from sources through a gateway if needed, shaped by dataflows or queries, loaded into a semantic model with relationships and measures, and shown by visuals on reports. Reports live in workspaces, are shared as apps, and run on a capacity. Row-level security decides what each person sees.

Here is how data flows from your sources to a person looking at a chart.

flowchart LR
  subgraph SRC["Data sources"]
    S1["Azure SQL and warehouses"]
    S2["Data lake storage"]
    S3["Streaming data"]
    S4["On-premises databases"]
    S5["Files and web services"]
  end
  GW["Data gateway"]
  S4 --> GW
  subgraph PREP["Preparation"]
    DF["Dataflows and queries"]
  end
  S1 --> DF
  S2 --> DF
  S5 --> DF
  GW --> DF
  S3 --> SM
  DF --> SM["Semantic model"]
  subgraph SVC["Power BI service"]
    SM --> RPT["Reports"]
    RPT --> APP["Apps and dashboards"]
    CAP["Capacity"] -.-> SM
  end
  APP --> USR["Users: browser, phone, Teams"]
  RPT --> EMB["Embedded in applications"]

The sources

Data starts in many places. Azure services supply much of it: relational databases, analytics warehouses and data lakes. Some data stays in offices on private servers. Some comes from files or web services. A good design lists every source, its owner, how often it changes and how sensitive it is.

Preparation

Raw data is rarely ready to show. Column names are cryptic, dates are in odd formats, and duplicates lurk. Preparation steps clean and reshape the data. They can run inside a single report file, or in shared cloud steps that many models reuse.

The semantic model

This is the heart. It holds tables, the relationships between them and the measures that calculate numbers. Everything on a report asks the model a question. A clean model makes reports fast and answers consistent.

The service and the capacity

The online service stores models and reports, runs refreshes, answers queries and manages sharing. Depending on the license, this work runs on a shared pool of compute or on dedicated capacity that you rent. Dedicated capacity gives predictable performance and additional features.

The viewers

Power BI licensing is the most changed part of the product. Treat this chapter as a map of ideas and verify details on the official pages.

Per-user licenses

A basic per-user license lets a person build and share content with other licensed people. A premium per-user license adds larger models, more frequent refresh and advanced features, but each viewer of that content also needs a matching license. This model suits small and medium teams.

Capacity-based licensing

With a capacity, you rent a block of compute. Content placed in a workspace on that capacity can usually be viewed by many people without each needing a paid license, depending on the capacity size and the current rules. Capacities come in sizes. They are the right choice for large audiences, heavy workloads and embedded scenarios. The current generation of capacity is sold as part of a unified analytics platform, and older premium capacity forms exist in parallel, with changes over time.

Embedded capacity in Azure

For software builders, there are capacities bought through the Azure portal and billed like other Azure services, designed for embedding reports into applications for customers who do not have licenses of their own. These can be paused and resumed to save money.

Where Azure fits

Azure is involved in three ways. It supplies the data services that models read. It supplies the identity system, so the same directory signs people in and defines groups for security. And it supplies, for embedding and some capacity types, the billing and resource management through the Azure portal. Many organizations also use Azure networking and key-management features to protect Power BI connections.

How a model gets its data decides speed, freshness and cost. This is one of the most important design choices.

flowchart TD
  Q["How should the model get data?"] --> A{"Data small enough to copy and refresh on schedule is acceptable?"}
  A -->|"Yes"| IMP["Import: copy data into the model"]
  A -->|"No, data huge or must be live"| B{"Source can answer queries quickly?"}
  B -->|"Yes"| DQ["DirectQuery: ask the source each time"]
  B -->|"No"| C{"Data is in a lakehouse or warehouse of the unified platform?"}
  C -->|"Yes"| DL["Direct Lake: read lake files directly"]
  C -->|"No"| MIX["Composite: mix modes, import small tables, query big ones"]

Import mode

The data is copied into the model and compressed in memory. Queries are very fast because they never leave the model. The cost is that data is only as fresh as the last refresh, and the model has a size limit. Import is the default choice for most reports.

DirectQuery mode

The model keeps no data. Each time a user clicks, the model sends queries to the source and shows the answer. Data is always current, and the size can be enormous. But speed depends on the source, and each click may place load on a production database. Not every calculation is supported, and many users clicking at once can slow things down.

Live connection

The report connects to a model that lives elsewhere, such as a shared model in the service or an analysis server. The report holds visuals only. This is the way to build many reports on one trusted model.

Direct Lake

A newer mode used with the unified analytics platform. The model reads data files in a lake directly, loading columns into memory as needed, giving import-like speed without copying the data on a refresh schedule. Availability and limits depend on the platform and are evolving.

Composite models

These mix modes: small, stable tables are imported, while large detail tables stay in DirectQuery. Aggregation tables, which pre-summarize big data, can answer most clicks quickly and send only detailed questions to the source.

Follow a single click from a user’s browser to a number on a chart.

sequenceDiagram
  participant U as User browser
  participant ID as Identity service
  participant SVC as Power BI service
  participant M as Semantic model engine
  participant SRC as Data source
  U->>ID: Sign in
  ID-->>U: Token
  U->>SVC: Open report with token
  SVC->>SVC: Check workspace role and security rules
  SVC->>M: Send query for each visual
  alt Import model
    M->>M: Calculate from memory
  else DirectQuery model
    M->>SRC: Send generated query
    SRC-->>M: Rows
  end
  M-->>SVC: Results
  SVC-->>U: Draw visuals

Step by step

Why imported models are fast

The engine stores each column separately and compresses repeated values. A column of one million dates with only a few thousand distinct values compresses to a tiny dictionary plus short references. Scanning a few columns of a compressed table in memory is very quick. The engine performs best when columns have few unique values and the model has a tidy shape.

Why too many visuals hurt

Every visual is a query. A page with fifty visuals can overwhelm both the model and the source. Simpler pages load faster, are easier to read and cost less to run.

Where time is spent

A good model is the single biggest factor in whether reports are fast, correct and easy to use.

Facts and dimensions

Data about a business has two kinds of tables. Fact tables record things that happen: each sale, each click, each payment, usually in huge numbers. Dimension tables describe the things involved: customers, products, dates, stores, in smaller numbers. A fact row says “customer 42 bought product 7 on this date for this amount,” and the dimension rows say who customer 42 is and what product 7 is.

The star shape

The recommended layout puts one fact table in the middle with dimension tables around it, each linked by a single relationship. This is called a star schema because the diagram looks like a star. It is simple to understand, fast to calculate and easy to filter: choosing a customer region filters the customer dimension, which filters the facts, which changes every number.

flowchart TD
  F["Sales facts: amount, quantity, keys"]
  D1["Date dimension"] --> F
  D2["Customer dimension"] --> F
  D3["Product dimension"] --> F
  D4["Store dimension"] --> F

Relationships

A relationship links a column in one table to a matching column in another. Most are one-to-many: one customer, many sales. The direction of filtering matters. By default filters flow from the one side to the many side. Allowing filters to flow both ways in many places creates ambiguity and slows calculations, so use two-way filters sparingly and deliberately.

Measures

A measure is a calculation that responds to the filters around it. “Total sales” adds the amount column. “Sales last year” shifts the date filter back twelve months. “Margin percent” divides profit by sales. The same measure gives a different number in every chart cell because each cell has different filters. The language for measures is built for this, and its strength lies in the idea of filter context, meaning the set of filters active at the moment of calculation.

Calculated columns versus measures

Modeling habits that pay off

The data has to get from where it lives to where the model can use it, safely.

Cloud sources

Azure data services such as SQL databases, analytics warehouses, data lake storage and big data engines have built-in connectors. A user signs in with their organizational identity or a service account, and the service can reach the source over the Microsoft network. For simple cases, nothing else is needed. For sources behind a private network, extra arrangements are needed, covered in the networking chapter.

The on-premises data gateway

Data inside an office network cannot be reached directly by the cloud service, because the firewall blocks incoming connections. A gateway solves this. It is a small program installed on a machine inside the network. It makes only outbound connections to the cloud service, keeps an open channel, and when the service needs data, the request travels down that channel, the gateway queries the local source and sends the results back. No inbound hole in the firewall is needed.

flowchart LR
  subgraph CLOUD["Microsoft cloud"]
    PBI["Power BI service"]
    RELAY["Secure relay"]
  end
  subgraph OFFICE["Your private network"]
    GW["Gateway machine"]
    DB["On-premises database"]
    FILES["File shares"]
  end
  PBI --> RELAY
  GW -->|"outbound connection only"| RELAY
  GW --> DB
  GW --> FILES

Two kinds of gateway

Credentials

Each data source in the service needs credentials stored securely. Prefer organizational identities and managed arrangements over shared passwords. When a person leaves, make sure that no important refresh depends on their personal account. Use service accounts with limited rights, or other non-personal identities.

Gateway sizing and resilience

The gateway machine needs enough memory and processor for the busiest refresh and live queries. A single gateway is a single point of failure, so production uses a cluster of two or more machines. Place them close to the data, keep them patched and monitor them. For heavy use, separate gateways for refresh and for live queries prevent one from starving the other.

Imported data goes stale. Refresh is the process that brings it up to date, and it needs as much care as the report itself.

Scheduled refresh

You set a timetable, such as every morning at six and every noon. At each time, the service reconnects to the sources, reloads the data, rebuilds the model and replaces the old copy. Limits exist on how many times a day a model may refresh, depending on license and capacity. A refresh can fail for many reasons: expired credentials, a source that is down, a changed column name or running out of memory.

Refresh duration and memory

During refresh, the service may need roughly double the memory of the model, as it holds the old copy while building the new. A model near the size limit may therefore fail to refresh even though it opens fine. Keeping models lean avoids this.

Incremental refresh

Reloading ten years of sales every night to pick up today’s few thousand rows wastes time and money. Incremental refresh divides the data into time slices. Old slices are kept as they are; only recent slices are reloaded. A refresh that took two hours may take five minutes. You choose how many past periods to keep and how many recent periods to refresh. The source must support filtering by date efficiently.

Dataflows

A dataflow performs the cleaning and shaping once, in the cloud, and stores the results so many models can reuse them. This avoids copying the same logic into many report files, and reduces repeated load on the source. If a data fix is needed, it is made in one place.

Refresh good habits

Event-driven refresh

Instead of a fixed clock, a data pipeline can call the service when it finishes loading, so reports refresh exactly when new data is ready. This reduces wasted refreshes and avoids showing half-loaded data.

How you organize and release content decides whether users find the right report and whether authors can change things safely.

Workspaces and roles

Apps for audiences

Workspaces are where authors work, and they should be limited to the team. Readers should get content through an app, a packaged and versioned set of items with its own audience groups. An app can show different pages to different groups. Authors keep editing in the workspace and publish a new version of the app only when ready.

Deployment pipelines

For serious content, use separate workspaces for development, test and production, linked by a pipeline. Authors build in development, the pipeline copies content to test where users check it, then to production. Rules in the pipeline change data source connections between stages, so a test report reads test data and a production report reads production data.

flowchart LR
  DEV["Development workspace"] -->|"deploy"| TST["Test workspace"]
  TST -->|"deploy after approval"| PRD["Production workspace"]
  PRD --> APP["App for readers"]
  GIT["Source control"] -.-> DEV

Source control

Report and model definitions can be stored as text files in version control. Teams then review changes, see who changed what and roll back mistakes. It also enables automated checks, such as scanning models for common problems before deployment.

Certified and promoted content

To help users find trusted models, owners can mark them as promoted, meaning the team recommends them, or certified, meaning an approved reviewer has checked them. A data catalog view then lets users search by name, owner and endorsement.

Sharing choices

Reports often show sensitive numbers. Security must be designed into the model, not added at the end.

Identity

People sign in with the organization’s directory, which supports strong sign-in methods and conditional rules, such as requiring extra verification from unknown locations. Groups in the directory are used to assign access to workspaces, apps and security roles, so managers manage groups instead of individuals.

Row-level security

Row-level security hides rows from users who should not see them. A sales manager sees only their region. A store manager sees only their store. You define roles in the model, each with a filter rule on a table, and assign groups to roles. Rules can be fixed lists or can look at the signed-in user’s name or email and match it to a table of permissions. Dynamic rules reduce the number of roles to maintain.

Object-level security

This hides whole tables or columns, for example salary columns, from some roles. The hidden items vanish from the field list, so users do not even know they exist.

Sensitivity labels

Labels, such as “internal” or “confidential”, can be applied to models and reports and follow the data when it is exported to files. They connect to the organization’s wider information protection rules and can enforce encryption or limit sharing.

Tenant settings

Administrators control many features through tenant-wide switches: who may publish to the web, who may export data, who may create workspaces, and whether guests are allowed. Review these regularly. A “publish to web” feature, for example, makes a report public to anyone with the link, so it should be tightly controlled or disabled.

Common security gaps

Many organizations require that data never cross the public internet. Azure networking features make this possible for Power BI.

Private connections to the service

You can require that users reach the Power BI service only through private links in your own virtual network, so traffic from offices and virtual machines travels over private paths. A setting can then block public internet access to the service for the tenant, or for specific content. This is a strong control, and it changes how every user connects, so plan carefully, especially for remote workers and phones.

Private connections to data sources

When the data source, such as a database or warehouse, has public access turned off and is available through a private endpoint, the service needs a way in. A virtual network data gateway is deployed into your virtual network, runs managed by Microsoft, and connects privately to those sources. This avoids running your own machines.

Conditional access

Rules in the directory can require compliant devices, known locations or extra verification before a user can open Power BI. They can apply different rules to different groups, such as stricter rules for administrators.

Encryption and keys

Data is encrypted in transit and at rest by default. Organizations with strict rules may supply their own encryption keys, held in a key storage service, for certain capacity types. Check the current availability and the effect on recovery if a key is lost.

Auditing

The service records activities such as viewing reports, exporting data, sharing, and changing settings. These audit records can be exported to a security system for alerts, such as an unusual large export. Keep them for the period your rules demand.

Sometimes the best place for a report is not a separate website, but inside the application people already use.

Two embedding styles

In embedding for your organization, employees who already have licenses see reports inside an internal portal or collaboration tool and sign in with their own identity. In embedding for your customers, a software company shows reports to external users who have no license and often no organizational identity. The application signs in on their behalf with a service identity and asks for a short-lived embed token for each session.

sequenceDiagram
  participant CU as Customer browser
  participant APP as Your application
  participant ID as Identity service
  participant PBI as Power BI service
  CU->>APP: Sign in to your app
  APP->>ID: Service identity requests access
  ID-->>APP: Access token
  APP->>PBI: Request embed token for report and user rules
  PBI-->>APP: Short-lived embed token
  APP-->>CU: Page with embed token and report address
  CU->>PBI: Load report using embed token
  PBI-->>CU: Report visuals

Capacity for embedding

Embedded content for customers must run on a dedicated capacity, which is bought in Azure by size, and can often be paused when not in use. Because the capacity is yours, you control costs and performance, and many customers can view without any license of their own.

Multi-tenant designs

A software vendor serving many customers must keep each customer’s data separate. Two main patterns exist. In the first, each customer gets its own workspace and model, giving strong isolation but more items to manage. In the second, all customers share one model, and row-level security isolates data using a customer identifier passed in the embed token. This is cheaper but demands careful testing, since a mistake could expose one customer’s data to another.

Application considerations

Slow reports lose users. Most slowness has a small set of causes that can be found and fixed in a methodical order.

Find the slow part first

A built-in analyzer records how long each visual takes to load, and splits that time into the model query and the drawing. A separate tool traces the queries sent to the model and shows the slowest. Always measure before changing, since the guess is often wrong.

Model fixes

Report fixes

Source fixes for live modes

When using DirectQuery, the source does the work. Make sure the source has the right indexes and statistics, use views that pre-join and pre-filter, and avoid calculations in the report that the source cannot translate efficiently. Consider a dedicated read replica so reports do not compete with the live application.

Capacity-level performance

If many users hit the same capacity at the same time, even well-built reports can slow. A monitoring app for the capacity shows which items use the most compute. Move heavy items to their own capacity, schedule heavy refreshes off peak hours and optimize the heaviest models first.

Dedicated capacity is a shared pool for everything in its workspaces. Managing it is like managing the electricity supply of a building.

What a capacity measures

Capacities are measured in compute units, which stand for processing power over time. Every refresh, query and background task consumes some. Interactive work, such as people clicking on reports, is sensitive to delay, while background work, such as refreshes, can be spread over time. The platform uses smoothing to average usage across a window of time, so short spikes do not immediately cause trouble.

When the limit is exceeded

If usage stays above the capacity for too long, the platform starts to slow or reject requests, called throttling. Interactive requests may be delayed or rejected, and background jobs may be postponed. The stronger the overload, the stronger the throttling. Users experience this as slow or failing reports, often with no change on the report side.

Sizing a capacity

Start by listing workloads: the number of users, concurrency at peak, model sizes, refresh counts and times, and any heavy calculations. The sizes are not linear, so test with real content. Many teams begin with a moderate size, watch usage for a few weeks using the monitoring app, and adjust.

A worked example

These numbers are illustrative only. Suppose a capacity can sustain an average of 64 units of compute. Business hours load is 40 units from users plus 10 from refreshes, so 50 units, which is 78 percent. At month-end, finance runs heavy reports, adding 30 units for two hours, giving a peak of 80. If smoothing averages usage over a period of that length, the average over the window could exceed 64, causing throttling. Fixes include moving finance’s items to their own capacity, rescheduling refreshes away from month-end mornings, or choosing the next size up for those days if the platform supports scaling on demand.

Ways to scale

Reports are only useful when they are available. Know what the platform protects and what you must protect yourself.

What Microsoft provides

The service is built across multiple machines and datacenters, and it fails over inside a region without your involvement. Some capacities can be set up with options for zone resilience or for a secondary region. Check the current documentation for exactly which protections your capacity type offers.

What you must protect

Recovery targets

Decide how long a report can be unavailable and how old its data may be after recovery. A board dashboard may tolerate hours; a customer-facing embedded report may tolerate minutes. Your answers decide how much to spend on redundancy.

A simple regional design

flowchart LR
  subgraph RA["Primary region"]
    CA["Capacity A"] --> WA["Production workspace"]
  end
  subgraph RB["Secondary region"]
    CB["Standby capacity B"] --> WB["Standby workspace with same content"]
  end
  GIT["Source control and deployment scripts"] --> WA
  GIT --> WB
  SRC["Source data replicated"] --> WA
  SRC --> WB
  APPU["Users and apps"] --> WA
  APPU -. "switch if primary fails" .-> WB

Practice the failover

Unused plans do not work. Once or twice a year, deploy the content to the standby, test refresh, test security rules and measure how long the switch takes. Update documents with what you learned.

Both the platform and your own content should be watched. A few views answer most questions.

Capacity metrics

A monitoring application, provided by Microsoft, shows capacity usage by item and by time, throttling events and which operations used the most compute. It is the first place to look when users report slowness.

Activity and audit records

These show who viewed, shared, exported or deleted what. Send them to a central store and build alerts for patterns like mass exports, new public links or deletion of production items.

Refresh history

Each model keeps a history of refresh runs with start time, duration and any error message. Review failures weekly, and track trends in duration, since steadily increasing time warns of growth problems.

Usage metrics

Usage reports show which reports are viewed, by whom and how often. They reveal unused reports that can be retired, and the most popular ones that deserve optimization.

Model-level traces

For deeper investigation of a model, an external tool can connect to the model engine and record query timings and memory use. Use it during development and when diagnosing production problems.

Alerts worth having

A troubleshooting walk

A Power BI bill has several parts, and the largest are often people and capacity. Prices change, so use the official calculator for real numbers.

A worked comparison

The numbers below are invented to show the method. Suppose a per-user license costs 10 dollars per person per month, and a capacity costs 5,000 dollars per month with no viewer licenses needed for the audience. For 100 viewers, per-user licensing costs 100 times 10, or 1,000 dollars, which is far cheaper than the capacity. For 1,000 viewers, it costs 10,000 dollars, which is more than the capacity. The break-even is 5,000 divided by 10, which is 500 viewers. Remember that authors still need licenses, and that capacity also gives larger models, more refresh and extra features, so the decision is not only about price. Check current official prices and rules.

Embedded cost example

Imagine an embedded capacity costing 1.00 dollar per hour in a small size. Running all month, 730 hours, costs 730 dollars. If your customers use the application only during business hours, about 12 hours on 22 days, that is 264 hours, and pausing at other times would cost 264 dollars, a saving of 466 dollars per month. Automation that resumes the capacity before the first user arrives makes this practical, though resume takes a short time.

Ways to reduce cost

Retire reports nobody uses, using usage metrics to find them. Reduce model sizes and refresh frequency. Use incremental refresh. Pause embedded capacity when idle. Share one trusted model among many reports instead of many copies. Use per-user licenses for small groups and capacity only when the audience or workload justifies it. Review licenses quarterly and remove those of people who left.

Power BI is the presentation and modeling layer of analytics. Other Azure services do the heavy lifting beneath it, and some compete for parts of the job.

flowchart TD
  N["What do users need?"] --> A{"Explore and interact with charts?"}
  A -->|"Yes"| PBI["Power BI report on a semantic model"]
  A -->|"No"| B{"Printable fixed-layout documents?"}
  B -->|"Yes"| PAG["Paginated report"]
  B -->|"No"| C{"Ad hoc queries on raw logs by technical staff?"}
  C -->|"Yes"| ADX["Query tool on a real-time analytics database"]
  C -->|"No"| D{"Data pushed into another application?"}
  D -->|"Yes"| API["Programming interface or data export"]
  D -->|"No"| REV["Revisit requirements"]

Power BI and its neighbors

A common architecture lets data engineering services collect and clean data into a lake or warehouse. Power BI then reads from there. Stream processing services feed live tiles. Power BI does not replace the warehouse; it is a layer on top. Treating it as the place to do heavy transformations or to store the only copy of business data leads to slow refreshes and fragile reports.

Other business intelligence tools

Other vendors offer competing tools, and some organizations run more than one. Power BI is most attractive when the organization already uses the Microsoft ecosystem for identity, office tools and data. Compare tools by license cost, connector support, governance features, skills available and integration with your data platform.

Spreadsheets still have a place

Spreadsheets remain useful for quick one-off analysis. Power BI models can be opened in spreadsheet tools through connections, giving users familiar pivots on governed data, which reduces the temptation to export and copy.

An honest look at what the service does well and where it brings limits.

Key trade-offs

Finding the balance

The healthiest organizations use a hub-and-spoke approach to responsibility. A central team owns core models, standards and the platform, while business teams build reports on those models and, within limits, their own models for local needs. Clear rules explain when something should be promoted from local to central.

Teams with good results repeat a handful of habits. Teams that struggle repeat a handful of mistakes.

Patterns that work

Anti-patterns to avoid

A checklist to apply before any report is released to a wide audience.

Best practices

Common mistakes

Walk through the failures in advance, and recovery becomes routine.

Scenario one: the morning report shows yesterday’s numbers

The scheduled refresh failed in the night because the source password had expired. Nobody noticed because failure notices went to the person who had left. Recovery: renew the credential, refresh, and tell users. Prevention: failure alerts to a shared mailbox, service accounts and expiry reminders.

Scenario two: everything is slow on the first of the month

Many finance reports run at once, and several large refreshes overlap. The capacity is throttled. Recovery: pause or reschedule noncritical refreshes, ask heavy users to wait, or add temporary capacity. Prevention: capacity monitoring, staggered refresh and a separate capacity for month-end work.

Scenario three: a user sees rows they should not

A manager reports seeing another region’s sales. Cause: the user was also a member of the workspace with an editor role, to which row-level rules do not apply. Recovery: change the role to viewer or give app access, and review who saw what using audit records. Prevention: separate authoring and reading, and periodic access reviews.

Scenario four: a schema change breaks the model

A database team renamed a column. The refresh fails and visuals show errors. Recovery: update the query to the new name and refresh. Prevention: communicate source changes, use stable views as the contract between source and model, and run automated checks in test before production.

Scenario five: the gateway machine is down

An update restarted the gateway server, and on-premises refreshes failed. Recovery: restart the service and rerun the refresh. Prevention: a cluster with at least two nodes, patching one at a time, and monitoring.

Scenario six: an embedded customer view shows another customer’s data

A bug in the application sent the wrong customer identifier in the embed token. Recovery: disable the report in the application, fix the logic, invalidate tokens, notify affected parties according to policy. Prevention: automated tests of the security rules for each customer pattern, code review and a second layer of isolation for high-risk data.

flowchart TD
  A["User reports a problem"] --> B{"Data stale or wrong?"}
  B -->|"Stale"| C["Check refresh history, credentials and gateway"]
  B -->|"Wrong"| D["Compare with source, review measures and relationships"]
  B -->|"Neither"| E{"Slow or failing?"}
  E -->|"Slow"| F["Check capacity metrics and performance analyzer"]
  E -->|"Access issue"| G["Check roles, row-level rules and sharing"]
  C --> H["Fix, refresh and confirm with the user"]
  D --> H
  F --> H
  G --> H

Technology alone does not create trustworthy analytics. People, rules and habits do.

Who owns what

Each model and report needs a named owner who answers questions, fixes problems and decides on changes. Data owners decide what the sensitive fields are and who may see them. Platform administrators manage tenant settings, capacities and gateways. A central support team trains users and runs a help channel.

A center of excellence

Many organizations create a small group, often called a center of excellence, to help the rest of the company use the tool well. It publishes standards, templates, naming rules and training. It certifies core models and runs office hours. It does not build every report; it helps others build good ones.

Standards worth writing down

Measuring governance

Track the number of certified models, the share of reports built on shared models, refresh failure rates, unused content, access review completion and the time to resolve problems. These indicators show whether the platform is becoming more or less trustworthy.

Training and culture

Teach three things to everyone: how to read a report critically, how to find certified content, and how to ask for help. Teach authors how to model data, write measures, secure content and optimize performance. A short, regular training plan avoids the slow drift into confusion.

These are typical, invented scenarios that show the ideas at work. They are not reports about any named company.

What they share

Each example starts from a clear audience and decision, builds a clean shared model, controls access with groups and rules, plans refresh and capacity, and watches usage. The tool was the easy part; the model, the security and the habits made the difference.

Short answers to common questions. Where a detail may have changed, confirm in the current Microsoft documentation.

Power BI turns data from Azure and other sources into models, reports and apps that people can explore, share and embed, if the model, security and capacity are designed with care.