Simplify Power BI DAX with Visual Calculations

Video by: Reid Havens

If you've ever written a running total in DAX, you know it's more work than it has any right to be. CALCULATE, FILTER, a column reference you have to get exactly right, and a quiet prayer that it behaves at the subtotal level. Visual calculations let you write RUNNINGSUM([Sales]) and get on with your day.

They're a calculation layer that lives inside the visual itself, working on the data that's already been aggregated rather than querying the whole model. That's also why they're often faster, sometimes dramatically so on DirectQuery.

I walk through the core functions (running totals, moving averages, PREVIOUS and NEXT for period comparisons, FIRST, LAST, INDEX, and RANK), then the hierarchy functions like COLLAPSE and EXPAND that make "% of parent" and "% of grand total" almost trivial. We also get into AXIS and RESET, which control the direction a calculation runs and where it restarts, because that's the part that quietly breaks people's running totals across years.

One honest caveat. Yes, they're easier and faster. But because each one only lives in a single visual, they can fragment your business logic across reports if you're not careful, so I cover when a visual calc is the right call and when it really should be a centralized measure.

DAX Fundamentals Part 3: The Patterns That Make Reports Work

You've learned how filter context and CALCULATE actually work. This is where it pays off. Part 3 of the DAX Fundamentals series covers the patterns you'll keep reaching for in real models, and why they behave the way they do.

We get into time intelligence (YTD, QTD, prior cycle, and why these functions return tables of dates rather than numbers), variables for cleaner and faster formulas, and SWITCH as the cure for nested IF chains nobody wants to maintain. Then inactive relationships and USERELATIONSHIP for when one fact table has two date columns fighting over the same date table.

The pattern that saves the most pain is calculation groups. Write three base measures, add one calc group with YTD, Prior Cycle, and YoY%, and you've replaced nine measures (and growing) with something you maintain in one place.

The video closes on the part most people skip: how the engine splits work between the Storage Engine and the Formula Engine, and why pushing work toward simple aggregations on a star schema is the difference between fast DAX and slow DAX.

Building Operational Systems on Databricks (with Andre Landgraf)Building Operational Systems on Databricks - with Andre Landgraf

LIVESTREAM DATE/TIME 📅

June 26th: 9:30 AM (Pacific Time)

DESCRIPTION 📄

There are two broad categories of systems: analytical systems and operational systems. Databricks is primarily known for the former. It’s an OLAP platform where organizations ingest, manage, analyze, and derive value from their data. This includes everything from business intelligence and analytics to machine learning models, AI workloads, and data pipelines.

The resulting insights, predictions, and AI-generated outputs need to flow back into operational systems that can act on them, whether that's powering an internal tool or personalizing a customer experience. This is even more true in the age of AI, where this data becomes context for agents. To make that possible, we need ways to channel analytical data back into operational systems (data apps, AI agents, and more).

In this session, I’ll give an overview of the Databricks capabilities that help operationalize analytical data. We’ll look at services such as Databricks Apps, Lakebase, and other platform components that enable you to build operational and agentic applications directly within your Databricks workspace. Let's vibe code an app from scratch and cover practical vibe coding best practices while integrating data from your lakehouse.

GUEST BIO (Andre Landgraf) 👤

Andre is a passionate developer from Germany who loves building for the web. Based in the Bay Area, he is a Staff Developer Advocate at Databricks. He was previously a Senior Software Engineer at LinkedIn and holds master’s degrees in Information Systems and Computer Science. In his free time, he brings the community together through All Things Web events in San Francisco.

RELATED CONTENT 🔗

Andre's X
Andre's LinkedIn
Databricks DevHub

Materialized Lake Views in Microsoft Fabric: How They Actually Work

Video by: Reid Havens

Every report hitting your raw tables runs the same expensive joins and aggregations over and over, even when the underlying data hasn't moved. Materialized Lake Views in Microsoft Fabric pre-compute those results once and store them as Delta tables in OneLake, so consumers read finished numbers instead of recalculating from scratch.

In this video I cover what MLVs actually are, how the automatic refresh logic decides between skip, incremental, and full rebuild, the Spark SQL syntax to create and manage them, and where they sit in a medallion architecture (think of them as a "Gold+" layer).

The part worth sticking around for: point Direct Lake at an MLV instead of your raw tables and you get pre-aggregated data at import speed. In the example here, a 50 million row fact table collapses to around 500K. Fewer rows means faster transcoding into VertiPaq and a lot less DirectQuery fallback risk. That's the single best reason to pair the two.

I also get into when NOT to use them, because they're not free. Sub-minute volatile data, tiny tables, and row-level security needs are all cases where an MLV is the wrong tool.