Frequently Asked Questions

Power BI in simple terms is a Microsoft platform that collects data from different systems and turns it into interactive reports and dashboards. It helps you quickly see the key metrics and the reasons they changed.

Power BI is used to analyse sales, finance, marketing, inventory and operational processes. It allows a company to automate reporting, keep track of KPIs and drill metrics down to an individual product, region or manager.

Yes. Power BI Desktop can be used free of charge to build reports, and the Fabric Free licence suits personal work in the service. Standard sharing requires Pro or PPU. Free users can also view content hosted on a Fabric F64 or larger capacity if they have been granted the relevant access.

Power BI Desktop is designed for preparing data, building models and creating reports. Power BI Service is used to publish them to the cloud, refresh them automatically, collaborate and manage access.

For learning and local work the free Desktop is enough. Pro suits teams that need to publish and view reports together. PPU is chosen for personal access to Premium features, and Fabric capacity for dedicated resources or a wide audience.

The best way to start is with a specific task and a small dataset. Connect an Excel file in Desktop, clean the data with Power Query, create a few basic measures and build your first Power BI report. This approach helps you grasp the logic of the platform faster than working through all its features one by one.

It is the infrastructure that collects data from all of a company's systems – CRM, ERP, advertising, warehouse – brings it into a single format and makes it available for analytics and automated decision-making. It is not a single database, but a combination of sources, storage, a processing layer and analytics tools that work as one whole.

Without one, departments calculate the same indicators differently and decisions are made on the basis of inconsistent figures. A unified data platform gives the whole company a single version of the truth: marketing, sales and finance see the same metrics, calculated with the same logic.

A data warehouse stores structured data in a fixed schema and suits financial reporting and well-defined BI dashboards. A data lake stores any data in raw form: files, logs, unprocessed datasets, and is better suited to large-volume analytics and ML models, where the structure is not known in advance.

A lakehouse combines the principles of a data lake and a data warehouse: it makes it possible to work with large volumes of diverse data and at the same time support structured analytics. But there is no universally better option: the choice between a data lake, a data warehouse and a data lakehouse depends on the types of data, the analytics tasks and the architecture requirements.

In a simplified architecture there are four main blocks: data sources and integrations, storage, the analytics and BI layer, and governance – the rules for access, quality and data management. In more complex platforms, data processing, cataloguing, monitoring and security tools can also be separate components.

Step by step: first an audit of the current systems, to understand which data sources are critical. Next – choosing an architecture that fits the scale of the business. Then building the ETL/ELT pipelines that move and transform the data. And only at the end – connecting the BI layer for dashboards and reports. Skipping the audit or trying to start straight from BI increases the risk that the platform will be built on inconsistent data and will need rework after launch.

RLS restricts access to individual rows of the data model depending on the user's role. That is why one and the same report can show different data to different people.

Create an RLS role, define the filter rule, test it, publish the model and assign users or groups to the role in Power BI Service. Separately check their workspace permissions and their access to the report.

In static RLS the filter rule is tied to a role. In dynamic RLS it can change depending on the user, for example through USERPRINCIPALNAME() and a mapping table.

This is done with RLS Power BI: the model's rules define which data a user sees after signing in.

In Power BI Desktop use View as to check the report on behalf of a role. After publishing, the role can also be tested in Power BI Service.

Typical mistakes: an error in the DAX filter, incorrectly assigned workspace roles, an outdated mapping table, and an attempt to replace RLS with ordinary report filters.