TITLE HERE - GUEST NAME HERE (Copy)

LIVESTREAM DATE/TIME 📅

DATE TIME HERE (Pacific Time)

DESCRIPTION 📄

Power BI tells you how many times a report was opened, but not whether people actually understood it, trusted it, or found what they needed. BI Pixie is a usage analytics and AI readiness solution for Power BI, now available as a native Microsoft Fabric workload.

In this session, we'll demo the latest BI Pixie features and take you on a journey from Power BI usage to AI readiness. We'll start by showing how BI Pixie captures what really happens inside your reports, with visual-level heatmaps, click and filter tracking, and in-report satisfaction signals that reveal which content drives value and which quietly gets ignored.

Then we'll move up the stack to the part everyone is asking about: getting your data ready for AI. You'll see how BI Pixie assesses whether your semantic models are ready for AI agents like Copilot, Fabric data agents, and MCP with an engagement-weighted Readiness Score; how it optimizes those models with targeted improvements; and how you can create benchmarks to verify the effectiveness of your data agents and semantic models over time.

If you own Power BI adoption and you're wondering how to prepare your estate for AI, this one is for you.

GUEST BIO (Gil Raviv) 👤

Gil Raviv is the founder of BI Pixie and DataChant Consulting, and a Microsoft MVP. Gil has led global BI practices at Avanade/Accenture and AWS and today focuses on helping enterprises measure and improve the adoption, trust, and governance of their Power BI reports through BI Pixie.

RELATED CONTENT 🔗

BI Pixie
Gil's LinkedIn

Posted on July 28, 2026 and filed under Livestreams, Fabric.

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

Posted on June 15, 2026 and filed under Livestreams, AI, Databricks, Data Platform.