PL-300: how to implement partitions and optimize refresh for Power BI models

João Barros 20 de October de 2026 4 min read

In this lesson I will teach you the skill: implement table partitions and refresh strategies for Power BI models. This ability is important in the PL-300 exam because it affects performance, resource consumption and refresh requirements in professional practice.

What you need to know

Partitioning a table means dividing it logically into segments (partitions) that can be loaded or updated independently. In the context of Power BI there are two main scenarios:

Imported models (in-memory / VertiPaq): partitions are normally managed automatically by the Power BI service, but when using the XMLA endpoint or external tools (Tabular Editor, Analysis Services) you can create partitions to control incremental processing.
DirectQuery and composite models (Composite models): there are no partitions in the import engine for DirectQuery, but you can use partitioning strategies at the source (for example, partitioned views) to control the volumes returned.

Advantages of partitions and incremental refresh:

Reduces refresh time by processing only new or changed data.
Minimizes maintenance windows and reduces impact on users.
Improves resource utilization and can reduce costs on large datasets.

How it works

The basic mechanism for efficient updates in Power BI is incremental refresh. Here is the conceptual flow:

Identify a partition column (e.g.: OrderDate, ModifiedDate, PartitionKey) that allows filtering by a time range or by partition keys.
Define policies: how many periods (days/months) to fully reprocess and which to only append (incremental).
On the first load perform a full refresh of the table; afterwards apply only the incremental criteria for new/changed data.

In Power BI Desktop (import model), you configure incremental refresh in the table settings in Power Query and publish to the service. In the service you need a Gateway when the source is on-premises.

In practice

Practical example: Sales table with OrderDate column. Summarized process (Power Query + Power BI Service):

1. In Power Query filter OrderDate to a window, e.g.: RangeStart and RangeEnd (DateTime parameters).
2. Create two parameters: RangeStart, RangeEnd (used only for query folding).
3. Apply filters using: OrderDate >= RangeStart and OrderDate < RangeEnd.
4. In Transform > Table > Incremental Refresh (in Power BI Desktop):
   - Enable incremental refresh for this table
   - Set store rows for (e.g.: 5 years)
   - Set refresh rows for (e.g.: 1 month)
5. Publish to Power BI Service. The service uses these settings to run incremental refresh during scheduling.

Important notes:

Query folding is critical: the filter between RangeStart/RangeEnd must be translated to the source (SQL, Synapse, etc.). Without folding, the service will do a full refresh.
For sources that do not support folding, consider using an intermediate table or an ETL process at the source (e.g.: Azure Data Factory) that already partitions the data.

Common mistakes

1) Relying on local filters: using dynamic parameters without query folding results in complete processing and negates the benefit of incremental. Always check whether the query folds to the source (View Native Query / Diagnostics).

2) Choosing the wrong column to partition by: using an unreliable column (e.g.: load date that changes) can lead to omissions or duplications. Prefer stable business columns (modification timestamp or event date).

3) Forgetting retention behavior: if you keep only X periods and later need older data, you will have to reprocess historically (full reload) or restore backups.

How to practice

Practice with a real dataset: create a fact table with several years and a ModifiedDate column. Follow the steps above and validate:

Test folding with tools like Power Query Diagnostics or the "View Native Query" option.
Make changes to older rows and check whether the incremental refresh policies capture them (for example, using Refresh History in the service).
Try combining Incremental Refresh with partitions defined via XMLA if you want to control partitions manually (requires Premium or PPU capacity to connect via XMLA).

For exam-specific practice, use the official Microsoft Practice Assessment (free) and the Microsoft Study Guide for PL-300 — both free and updated. Do not use unofficial question banks or dumps.

Summary

Partitions and incremental refresh reduce refresh time by processing only new/changed data.
Query folding and the choice of partition column are decisive for success.
Test and validate in Power BI Service: view refresh history and use diagnostics to ensure folding.
For advanced control (XMLA) and manual partitions Premium/PPU capacity is required.