Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Why the number you want is hard to get. That growth number in your power BI report doesn't exist yet. Power BI won't show you sales versus last year until someone writes the calculation behind it. And that calculation is where most beginners stop. The language is called Dax, and Quick Measure suggestions is Microsoft's attempt to get you past it. You describe the measure in plain English, and the tool writes the formula and explains what it built. It handles the common patterns well, and it gets things wrong when your business has its own definition of a word. What a measure really is and why templates weren't enough. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today's topic is a single power BI feature. It's the one that promises to write your calculations for you, and it's worth understanding properly before you trust a single number it produces. There's a strange gap in power BI that catches almost everyone. You can see a column of sales figures sitting in your table, and you can drag that column into a chart and watch it work. What you can't see anywhere is growth versus last year? Because that value isn't stored in your data at all. A measure is how power BI fills that gap. It's a small saved calculation that lives inside your data model, and it recalculates itself based on whatever the report is filtered to right now. Choose a different region or a different month. And the measure answers for that region and that month. A plain column can't do that because it's fixed the moment your data is imported and it has no idea what the person looking at the report clicked on. Those measures are written in a formula language called Dax, which is short for Data Analysis Expressions. Dax is what stops beginners cold. It carries its own syntax, its own rules for handling dates, and its own way of describing filters so you can know exactly what you want to see. And the tool will still wait for an expression you don't know how to write. Say you want average order value per region. Every one of those words is something you say out loud every week in Dax, each of those words turns into a decision about which column to add up, which table to filter, and what to show. When a region has no orders, that last decision decides whether the region shows a blank cell or an error. None of this is meant to scare you off. And the reason is simple a report that ships with the wrong total still looks finished and somebody will make a decision on it. Microsoft saw that wall a long time ago. Back in April twenty seventeen, it shipped a feature called Quick Measures, which handed you a list of ready made calculations. You picked one from the list, filled in the fields the dialog asked for, and power be. I wrote the Dax in the background for you. The list was handy. It covered averages and variances per category, filtered values, time, intelligence like year to date and month over month change, running totals, basic math, and a couple of text tricks like star ratings. The trouble with a fixed list is simple it can only cover the ways other people describe their numbers. So your finance team might want change against the same month two years ago and find no button for it. Once your calculation gets slightly unusual, the list runs out and you're back at a blank formula bar. Quick measure suggestions answers that exact problem. Instead of picking a template from a list, you write the measure out in a plain sentence and let the tool do the writing. What Quick measure suggestions actually does. Here's the plain version. You type a description of the measure you want in ordinary words, and the tool proposes the calculation that would produce it. Then you accept the suggestion, ask for another one, or refine what you asked for until it matches what you meant. That sounds like a small change from picking a template and it isn't. A template asks you to fit your question into its shape. A description lets you keep your own wording, and that matters as soon as your team has its own vocabulary for things. Take a request like orders per customer last quarter. There's no template for the exact phrasing your team uses, and there doesn't need to be because you aren't looking for a template. You're looking for a calculation that answers the sentence you just wrote. It also isn't the same tool as the question box you may have seen in power BI. That one, called Q&A, takes your sentence and gives you back a chart. Quick measure suggestions, takes the same sentence and hands you the calculation itself, which you can then reuse in any chart in the report where you find it has moved since it first appeared. The original version lived behind a preview switch and showed up as a suggestions tab inside the Quick Measure dialog. Today the same idea arrives mainly through copilot inside Dax Query View. The newer part of power BI desktop, built for writing queries by hand. What it reads is worth understanding because it explains both why it works and why it sometimes doesn't. The tool looks at your model's metadata, which means your table names, your column names, your existing measures, and the relationships between your tables. It doesn't read the rows of your data unless you direct it to. That's why it can take a vague request like sales growth, and work out which column holds the sales amount and which table holds your dates. It isn't guessing from a generic script because it's reading the shape of the model you built. The part that surprises people the first time is how specific the result is, because your own column names come back inside the formula. Instead of placeholders, you have to swap out. So the idea is simple, and what it feels like in practice is more interesting than that. It's worth seeing this from the chair you're actually sitting in. What happens when you actually ask for a measure? The setup step is small, and it's the step that makes people think the feature doesn't exist in power BI desktop. You open file, then Options and settings, then options, and under Preview features, you switch on the setting for Dax Query View. With copilot. Then you restart the app because that switch doesn't take effect until you do. Once it's on, it lives in Dax query view, which is the fourth view down the left side of power BI desktop. You create a new query tab and open copilot with the keyboard shortcut control and I. Then you type a sentence something like year over year sales growth as a percentage works fine. Moments later, you get back three things, which are a name for the measure, the Dax formula itself, and a short written explanation of what the tool decided to build. Picture the first time you try it. You have a monthly sales report open. You need average order value for each region, and instead of staring at the formula bar, you write that sentence. A few seconds later, there's a measure sitting in front of you with your own table names already inside it. That explanation is the part people underrate. It tells you why the calculation is shaped the way it is in words you can read. That turns a feature which could have been a black box into something closer to a worked example built on your own data. You can also ask it to change something you already wrote. Select the query, describe the edit you want, and the tool highlights the difference so you can see exactly what moved before you accepted. The tool checks its own work to before it shows you anything. It runs a syntax check on the formula it generated and retrieves your request once if something came out malformed. If the second attempt is still broken, it hands the problem back and tells you there's an issue, which leaves you to rephrase the request or fix the formula yourself. You aren't forced to accept anything either. You can run the query and see the actual numbers before you keep it, and then decide whether to keep it or throw it away. That run before you keep step is a small detail, and it's the line between an assistant and an autopilot. Because the tool read your table names and your date table before it wrote anything, the measure usually fits your report. Instead of looking like a snippet copied from a forum, it knows what you called things, so it uses your names so the mechanics are friendly. And that's exactly why the next question matters more than you would expect. Friendly isn't the same as correct where it actually shines. Start with the area where it wins. Most often, time intelligence is where the tool earns its keep. Year to date totals month over month change. Rolling twelve month averages and comparisons against the same period last year are all patterns it handles well. It even copes with the awkward case where some dates have no transactions at all. That last detail matters more than it sounds. Date handling is where handwritten calculations usually go wrong. First, because the obvious approach counts the days you happen to have data for, instead of the days that exist in the calendar. Take a simple one you want this month's orders next to the same month last year, shown as a percentage. Writing that by hand means knowing which date function to use, how to shift the calendar back a year, and how to divide safely when a month has no orders. Asking for it in a sentence means all three decisions get made for you, and the explanation names the function that did. The shifting ratios are the second strong area. Ask for percentage of total sales by category and you get something clean. The tool reaches for the safer divide function rather than the plain division symbol, and that single choice prevents the error. Most beginners hit when a category happens to have no sales. Filter ratios work too, and these are the ones that normally send people to a forum. Customers who bought this year, but not last year, is the kind of question that takes a careful read of how you filter a table, and the shape it returns is usually right. The fourth place it earns its keep is the tweak. You have a measure that's almost what you want, and you can't see which part to change. You describe the adjustment in a sentence and you get a new version to compare against the old one. The list of things it can attempt is longer than you might expect. It covers aggregated columns with or without filters. Counts of rows. Most or least common values. Top values for a category and simple conditions alongside the time, intelligence and ratio patterns already mentioned. For someone learning this stuff, the value is easy to describe. An afternoon of fighting syntax turns into a few minutes, and a junior analyst ends up with something real to show instead of a blank formula bar and a headache that doesn't make the tool smarter than you are. It means these particular patterns have been written so many times in so many models, that the common shape is well understood, and the tool reproduces that shape quickly. That strength also points straight at the weakness. The tool is at its best where the pattern is common, and your business is rarely at its most common in the places that matter. Where it gets things wrong without warning. The danger here isn't obvious nonsense. If the tool handed you a formula full of errors, you would spot it in seconds. The real danger is a measure that looks finished, uses the names from your model and is wrong in a way nobody catches for six months. This matters for your bottom line, because a wrong measure and a right one look identical in a chart. You might think the problem is a badly written formula, but it's actually a missing conversation with the business custom. Business logic is the first place it slips. When consulting team described a client whose definition of an active customer varied by region inside a loyalty program, the tool had no way to know what active meant in that business, and spelling it out in the prompt turned into writing code in English, which is slower than just writing the calculation. Models that carry two fact tables are the second weak spot. If you have a sales table and a returns table and you ask for net sales, the tool tends to pick one of them rather than combine the two properly. Performance is the third and this one hides the longest. A generated calculation can be correct and still be the slow version. One team described the gap as the difference between a two second visual and a thirty second one on a very large table. That's the kind of thing you only notice when the report meets real data volumes. Governance is the fourth. The tool doesn't know your organization's rules, such as routing every currency conversion through one specific exchange rate table. With specific filtering, it writes something that looks reasonable and breaks your rules, and that error can take months to trace. Then there's the smaller, slower problem of consistency. If you've already built fifty measures that follow one naming convention, the tool won't match that style. It writes in its own, which leaves you with a model where two measures that do the same job look like they came from different companies. The failures aren't spread evenly either. Time intelligence is the strongest area, and custom logic is the weakest, so the risk tracks how unusual your business is rather than how hard the formula looks. So the answer to the question planted at the start is a clear yes. It can be wrong, and the wrongness rarely announces itself. It arrives looking like a finished measure before you decide whether that risk is worth it. There's a bill attached, and it isn't the one you're expecting. The costs and limits nobody mentions first. The first limit is the gate that stops most people. The natural language path runs on copilot, and copilot needs a workspace backed by a paid fabric capacity. Microsoft says it's switched on by default for tenants whose capacity is EF2 or higher, and a dedicated copilot capacity has to sit on at least an EF2 or P1. For a beginner on a home laptop, that's the whole story in one line. The free desktop app still gives you the template Gallery from twenty seventeen, and the natural language part waits for a capacity sitting behind your workspace. That gap explains the most common complaint about the feature in a lot of organizations, the AI features are locked down while the security and governance people work out their own rules, so the button simply isn't there. It shows up, grayed out with no useful explanation, and a demo that worked beautifully on a personal tenant can be completely unavailable at work. Geography adds another layer. The service that powers it runs in US data centers and inside the EU data boundary. If your capacity sits anywhere else, copilot is off by default until an administrator turns on Cross-region processing, which means the setting lives with someone else. The privacy story is better than most people fear. What leaves your tenant is model metadata. That means table names, column names, and measure names and not the actual rows in your tables. Unless you ask for that column, names can still carry a client name or a detail you'd rather not share. So it's worth a conversation with whoever owns security before you point it at a sensitive model. There's also a size ceiling. The same documentation warns that past certain thresholds, including a model with more than five hundred tables or more than five thousand measures copilot can be unavailable or work from a reduced version of your metadata. It may also miss functions that were added recently. One last cost and it's the one finance notices. Copilot usage consumes fabric capacity, so heavy use of it draws on the same pool as everything else running in that tenant. None of that makes the feature a bad idea. It makes it something you check the prerequisites for before you promise anyone anything, which is what separates a good demo from a working rollout. How to use it without getting burned. Here's the rule that ties this whole episode together. Treat it as a draft tool, not a delivery tool. One consultancy that uses it on client work puts it this way. You treat the output the way you'd treat a code review from a clever junior, and you keep roughly seventy percent of what it generates while you rework the rest. That's their experience rather than a published benchmark, and the number matters less than the habit behind it. Three moves make the difference. Name the measure yourself before you accept anything. A suggestion arrives with its own name and house style, and a model full of mismatched names is a model nobody wants to maintain. Then read the explanation. It's the fastest free lesson in the tool, and it tells you which function did which job in the context of your own data, rather than a stranger's sample report, then test the number against something you already trust. If your monthly total doesn't match the finance report, the calculation is wrong, no matter how confident it looked. That reframe is the real point of this episode. The win isn't that you skip learning Dax, because every source on this feature says the opposite. The win is that you get a worked example on your own numbers with an explanation attached, which is a far quicker way to learn than reading syntax on a help page. Teams have started using it exactly that way, comparing a handwritten calculation against the suggested one to see the pattern that should have been used, the explanation tells them why. So here's the short version to take away quick measure suggestions. Turns a plain sentence into a working power BI calculation. It's useful for the common patterns, and it will hand you something confident and wrong whenever your business means something slightly different by a word, check the explanation, test the number, and keep the habit. One question for you before you go. What's the one number your team argues about every month? And would you trust a machine to write it? Tell us in the comments if this made the topic feel less intimidating. Subscribe to M365 FM to master the tools and the mindset shaping the future of work.