Imagine you’re analyzing a company’s sales data. You have a sale date, a delivery date, and an invoice date. You want to compare trends based on when sales occurred versus when orders were delivered, and you need filters and aggregations for both. What’s the best way to model this? The Problem with a Single Calendar
By default, Power BI incremental refresh partitions only include data up to the current period, leaving future-dated entries excluded. This can be problematic for scenarios requiring forward-looking data. In this article, we demonstrate how to modify the partitioning logic to include future dates within the most recent partition. While this example focuses on day-level refresh
“Work smart, not hard” is a powerful aphorism of universal application. In this article, I share what I have learned about increasing productivity in Power BI. I won’t be sharing tips or tricks on speeding up queries or creatively formatting visuals. My focus is to share high-level lessons with intermediate and advanced Power BI professionals
Incremental refresh in Power BI typically implements a rolling window for dates and data, as shown in this image from the official documentation: But what if you need to archive data starting from a specific fixed date? In other words, instead of a rolling window, you want the window to expand over time while preserving
Row-level security (RLS) in Power BI allows restricting what data users can see via boolean DAX expressions; this is done per dataset. I never thought much about what it meant for a user to be assigned multiple roles until it came up in a meeting, in which I quickly declared “it would be the AND
When retrieving data from a relational source like SQL Server, always use views to decouple reports from the underlying database table structure. Avoid embedding queries directly within reports. From a maintenance and development perspective, updating a view is more efficient and less error-prone than modifying a report query and republishing the report. Additionally, if possible,