IGLOO BI

The first step to mastering DAX is understanding the "identity of a value." You must clearly define whether what you are creating is "fixed historical data" or a "real-time response" that changes based on a user's question. 1. Calculated Column: A Fixed State Determined at Data Loading A Calculated Column is computed row by row during the data refresh process and is physically stored as a value within the data model. Once calculated, it does not change based on slicers or filters in the report. Calculation Timing: Performed only once during the data refresh. Operating Principle (Row Context): It scans each row one by one and completes the calculation using only the values present in that specific row. System Characteristics: Slicers or filters on a report cannot change the "result value" of a Calculated Column. Slicers merely determine "which rows to show" (Visibility). Primary Uses: Values to be used as slicer items (e.g., Age Gr...

When executives look at a weekly dashboard and ask, "Wait, why is this number different from last week?" a cold sweat runs down your spine. It would be a relief if an error message actually popped up. The truly terrifying situation is when the data looks perfectly fine, but the report is quietly outputting the wrong numbers. Today, we will dive into two types of "Silent Errors" that can instantly destroy your report's credibility and explore their solutions from a practical perspective. Related Anti-Patterns BLANK Anti-Pattern 5: Silent Error Masking BLANK Anti-Pattern 7: Filter Context Conflict While these two patterns differ in nature, they lead to the same disastrous conclusion: "The report looks normal, but the decision-making is wrong."   1. Data Reliability: The Invisible Crack Anyone can notice when a report breaks, allowing for immediate fixes. However, when a report appears normal but data-driven decisions are flawed, the entire organization s...

   When a Power BI report starts lagging, most people immediately suspect the data volume or the number of visuals. However, in practice, performance degradation often stems from very small DAX design choices. A prime example is measures that perform unnecessary calculations until the very end. Performance Issues are Discovered Later Than "Wrong Results" As seen in [Mastering BLANK Part 3-2], issues with incorrect totals are noticed relatively quickly. Performance issues are different: At first, it just feels "a little slow." As data grows and pages get complex, the lag becomes tangible. Eventually, the screen freezes every time a slicer moves, and users lose trust in the report. By this point, the report often has a structure that was destined to be slow from the design stage. Related Anti-Patterns BLANK Anti-Pattern 4: Performance Killer BLANK Anti-Pattern 6: Redundant Calculation The commonality between these two patterns is clear: "Calculating to the end ev...

This guide focuses not just on numerical accuracy, but on the critical moment when "Interpretable UX" collapses.   Ghost KPI & Static Status: Why "Silent Numbers" Ruin Your Reports After deploying a Power BI dashboard, have you ever received feedback like this? "I selected a slicer, but the KPI card is completely empty." "Sales are $0, so why does the status still show as 'Achieved'?" Technically, the numbers within the data engine are correct. However, if a user looks at the screen and tilts their head in confusion, it’s not a data error—it’s a failure in "Interpretable UX" design. Mastering BLANK in Power BI [Part 3-2], we will focus on two major culprits that erode report credibility: the Ghost KPI (Blank Card) phenomenon and the Static Status (Dead Column) problem. We will go beyond simple formulas to cover how to "respond kindly" to users with the COALESCE function and the practical reasons why you must use ...

When building Power BI reports, there are times when we need to hide performance data that falls below a certain threshold. However, have you ever experienced a situation where the Grand Total at the bottom doesn't match the sum of the numbers visible on the screen, breaking the data integrity? This is an incredibly common issue in the field and is the primary culprit behind the sudden collapse of report credibility. Today, we will dive deep into one of the most fatal BLANK anti-patterns: the "Total Row Destroyer." I will explain why this is problematic and show you how to fundamentally solve this by redefining the Filter Context (the target of aggregation) rather than using temporary post-processing like DAX's ISINSCOPE. Core Questions Addressed in This Article: Why does the sum of visible numbers and the Total constantly deviate? Why does BLANK become a "trap" instead of just a "hiding" mechanism?   1. Basic Data for Analysis (Sales Table) To ...