u/data_daria55

manually managing who sees what breaks down fast past a handful of people, so RLS stops being optional. concurrent queries plus overlapping refreshes start actually showing up as real slowdowns instead of hypothetical ones.

varying levels of Power BI literacy means a report that made sense to your five power users needs actual navigation and tooltips for everyone else.

and monitoring stops being a nice-to-have because you genuinely can't tell what's breaking without usage data. a lot of "why did this suddenly get complicated" moments are just this transition happening without anyone planning for it

GUIDs, order numbers, anything nearly-unique per row need a massive dictionary and codes almost as big as the original values. seen a single order-number column eat over 20% of an entire model's size while contributing literally nothing to any actual query.

Tip: before assuming your model is "just big," sort columns by size in VertiPaq Analyzer - usually one or two columns are doing almost all the damage

the June update put a modeling agent in the Service that renames tables, builds relationships and writes measures from a plain prompt

What do you think, ppl, about copilot new capabilities? Do you use it? Is it good?

Most feedback threads get you "looks clean, maybe try a different palette." that's politeness, not feedback.

post a screenshot here and I'll take it apart properly.

Screenshot is enough. blur anything confidential, I don't need real numbers to check whether they're internally consistent.

three things to include:

1. who it's for, exec / analyst / ops team
2. the one question it's meant to answer
3. what you already suspect is off

that third one matters. "tell me what you think" gets a worse review than "I think the top left card is doing nothing"

Funnel charts for strict linear stages (marketing cares about this).

Sankey for messy non-linear paths where people skip/reenter (also marketing, different question). cohort retention matrix for "are people actually coming back" (product cares about this one).

KPI + decomposition for leadership who want the headline number and the lever to pull, not the raw funnel.

picking the wrong pattern for the audience is why half these dashboards get built and then nobody opens them again

Saw a recruiter's post: a candidate for a senior (non-technical) role got caught reading AI-generated answers during the interview. Instant rejection - and the recruiter said it damaged his own reputation for having sourced the person.

Where's the line for you? Prep with AI is fine, real-time teleprompter is not? Or will this be as normal in a couple of years as googling syntax during a work task? What do you think?

model had a direct fact-to-fact relationship that worked fine at 2M rows and started timing out at 15M, because the hash join cost doesn't grow linearly, it explodes! nobody "broke" anything, the model just outgrew its own structure.

what to do: worth checking table sizes over time if a previously-fine report starts crawling with no obvious cause

UPN casing mismatches, guest accounts, service principals - none of that shows up in the simulated view, only with real credentials

Microsoft released a lot over the last two months (yes, you can catch a FOMO) - good news is - major of developers probably don't need 80% of it.

These are the updates I would actually pay attention to:

1. DAX User-Defined Functions are now GA

You can finally create reusable DAX functions instead of copying the same calculation logic across multiple measures.

Good use cases: repeated variance logic, reusable transformations, currency logic, common business calculations.

But don't turn your model into a software engineering project just because you can. VAL vs EXPR affects evaluation context, and UDFs have some non-obvious limitations - including OLS not automatically carrying over to a function.

2. The new Date Picker slicer is actually useful

It combines manual date selection and relative periods in one slicer. Even better: relative periods can be anchored to Today, First date, or Last date in your data. That last option is very useful for corporate datasets that don't refresh up to today's date.

! relative dates in published reports still use UTC, and users are already running into timezone surprises.

3. Conditional formatting finally works properly with legends and line charts

This is GA now for line, bar, column, pie and donut charts with legends.

The useful part: you can drive colors from one DAX measure, instead of manually maintaining colors across visuals. You can even return named theme colors such as good, bad, or neutral, so the formatting follows your report theme.

4. TMDL View is now in Power BI Service

You can edit semantic model metadata as code directly in the browser.

For a regular developer, I wouldn't learn TMDL as a programming language. Use it for bulk edits, copying objects, descriptions, repeated model changes.

5. Copilot can now actually edit your semantic model

Not just suggest DAX. In web modeling it can create or modify measures, tables, columns, relationships, descriptions, display folders and even RLS roles.

My practical use: repetitive cleanup and simple modeling tasks.

I would still review anything involving relationships, business logic or security. Microsoft creates a restore checkpoint before Copilot starts editing, which tells you something about how you should treat it.

6. Modern visual defaults are getting much better

You can now control more report-wide styling through the theme UI instead of formatting the same things over and over again. The new defaults are still preview, so I wouldn't blindly migrate existing corporate reports yet.

The bigger pattern here isn't “Power BI added more features.”

It's that everyday Power BI development is slowly getting less repetitive: reusable DAX, better defaults, better bulk editing, better date UX, and AI doing some of the boring model maintenance.

That's the part worth paying attention to.

one slow visual - report/rendering issue, check if it's one specific heavy visual or a long slicer list.

whole report slow - dataset/model issue, check for complex measures or model bloat.

multiple unrelated reports all slow at once - source issue, not a Power BI problem at all.

this one distinction alone saves a ton of wasted debugging time because it tells you which layer to even start looking at

if you're on DirectQuery and things feel sluggish, run the same query directly against the source (SQL, whatever). if it's slow there too, that's your answer - it's the source system, the network, or the gateway, not the report. people burn hours rewriting DAX or tweaking visuals when the actual bottleneck was never in Power BI's hands to begin with

-50K on a €1M month is a 5% dip. -50K on a €150K month is a third of it gone. same absolute number, completely different story. waterfall chart on top for the € delta, lollipop chart underneath for the % delta, same time axis for both. size first, then weight. way better than picking just one and hoping people do the mental math themselves

static RLS ([Region] = "North") is dead simple and easy to audit, but you need one role per segment and any org change means editing the model and republishing. dynamic RLS through USERPRINCIPALNAME() plus a separate UserSecurity mapping table means one role covers everyone, new hires just get added to a table row, no republish needed.

if you've got a small fixed number of categories, static is genuinely fine. if your user list changes monthly, dynamic saves you from babysitting the model forever.

concurrent queries stacking on top of refreshes, RLS needing actual structure instead of manual access management, capacity throttling becoming a real thing instead of a hypothetical - none of this shows up when it's just you and four coworkers testing.

if your report is about to go from a small team to a big rollout, worth stress-testing before launch, not after the complaints start

sometimes a developers gets a relationship warning or wants two fact tables talking to each other directly, flips it to many-to-many, warning's gone, moving on with their day

two flavors of this I keep running into.

first one's a dimension table that's not actually clean - CustomerID has duplicates in dim_customer because of some upstream data quality mess, and M2M just quietly lets you keep going instead of fixing the actual table

second one's when Sales and Inventory both have ProductID so someone just wires them together directly. fact tables aren't supposed to talk to each other like that, and M2M here is just ambiguous filtering with extra steps

end result is the same either way - filters get weird, totals look fine at first glance but don't actually foot right, and every fix after that point means bolting more DAX onto something the model should've handled

real fix is boring. clean up the dimension so the keys are actually unique, or if two facts genuinely need to relate, use a bridge table instead of just connecting them

sometimes a developers gets a relationship warning or wants two fact tables talking to each other directly, flips it to many-to-many, warning's gone, moving on with their day

two flavors of this I keep running into.

first one's a dimension table that's not actually clean - CustomerID has duplicates in dim_customer because of some upstream data quality mess, and M2M just quietly lets you keep going instead of fixing the actual table

second one's when Sales and Inventory both have ProductID so someone just wires them together directly. fact tables aren't supposed to talk to each other like that, and M2M here is just ambiguous filtering with extra steps

end result is the same either way - filters get weird, totals look fine at first glance but don't actually foot right, and every fix after that point means bolting more DAX onto something the model should've handled

real fix is boring. clean up the dimension so the keys are actually unique, or if two facts genuinely need to relate, use a bridge table instead of just connecting them

"86% resolved" tells you nothing about scale. "86%, 120 of 140" tells you the story - is this a big queue or a small one, is 14% remaining 2 tickets or 200.

always show both together where space allows. costs you a few extra characters of label, saves the viewer from having to ask "ok but out of how many"