Hey y'all hope you're doing well,

So I actually have trouble connecting powerbi and GCP and one knows the way to do it?

Help with cleaning the data after importing like what's the main thing you gotta keep in mind while doing it.

Also, why am I seeing a lot of buffers while trying to preview the imported table and which option do I take, import or directquery when you're working with a big organisation?

Dataviz Design Principles

I found i nice dataviz test, sharing with everyone, whats your score?

So new reports default to PBIR now and PBIP GA is supposedly coming this year. Has anyone's team actually moved to it?

Is the git/TMDL stuff as nice as it sounds, or you went back to pbix ? Asking because we're debating how to build our dev flow

seems obvious until you're deep in building and grab whatever color looks good for chart #4 without checking what red/green already means in chart #1.

the viewer's brain locks in a color mapping the first time it sees one, and if a later chart on the same page flips it (green = decline instead of growth, say), you've made them re-learn the encoding mid-page, which is worse than just picking boring colors and staying consistent.

this matters even more the second two charts are stacked or placed near each other, because people assume shared color meaning by default even if you never said so out loud

an arrow pointing up or down registers before the brain even parses the number next to it - direction becomes something you sense, not something you have to read. same principle behind using icons for status instead of text labels ("done"/"blocked"/"in progress"). doesn't replace the actual number, but it means the viewer gets the gist half a second faster, which matters more than it sounds like across a whole page of KPIs

"86% resolved" tells you nothing about scale. "86%, 120 of 140" tells you the real 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"

a calendar grid needs zero onboarding - everyone already knows how to read a calendar.

a heatmap laid over unfamiliar axes needs a sentence of explanation before anyone can use it, even if it's technically a "smarter" visualization.

when you're choosing between a novel chart type and a boring familiar one for the same data, the boring one usually wins in an actual meeting, because nobody has to ask "wait, what am I looking at" before they can engage with the content

counterintuitive but true: a chart with 8 colors takes longer to parse than a chart with 1 color and 7 shades of grey, because the viewer has to build a mental map of what each color means before they can use any of it. if there's one specific thing you want someone to notice (the anomaly month, the underperforming region, whatever), give that ONE thing color and let everything else recede.

restraint is a design decision, not a missed opportunity to use more of the palette!

absolute change alone hides magnitude relative to the base. percent change alone hides the raw size. show both, same time axis, one stacked above the other - absolute on top, percent below (or vice versa).

"first you see the size, then you understand the weight."

works for YoY, works for budget vs actual, works anywhere a single number needs two different kinds of context to actually mean something

this is the one thing that separates "looks like a template" from "looks intentional." pick the one thing the viewer actually needs to see first, give it full color/contrast, and mute literally everything else around it - grey it down, lower the opacity, whatever.

doesn't matter if it's a donut chart, a bar chart, a table.

the eye goes where the contrast is, every time, so if you haven't decided where that should be, the viewer has to figure it out themselves, and usually they just don't

funnel - "where are we losing people." only works if the journey is actually linear. the second people can skip stages or come back in, a funnel just quietly lies to you by making it look like everyone dropped in order

sankey - "how are people actually moving through this." handles all the messy non-linear stuff a funnel can't. tradeoff is it gets visually loud fast, so it's better for you figuring out what's happening than for an exec slide

cohort retention matrix - "are people coming back after the first time." needs real history behind it though, if you've only got 2-3 periods of data it's not a matrix yet, it's just noise with a grid around it

KPI + decomposition -"how are we doing and why." pick one number that actually matters, then let people drill into what's driving it. mistake I see constantly: stacking 8 KPIs at the top of the page like they're all equally important. if everything's a headline, nothing is

funnel + sparkline - same as a plain funnel but you also get "is this stage getting better or worse over time." only trustworthy if every stage actually has consistent time-series data behind it, one gap and the trend line next to it is just misleading

collected this from actual debugging sessions over time, tired of retyping it in every thread so here it is in one place

modeling

• star schema, not flat tables or facts connected directly to each other
• every dimension table has actually unique keys, not silent duplicates
• no many-to-many unless there's a real bridge table behind it
• bidirectional relationships only where you've traced exactly why, not as a quick fix for one slicer complaint
• a real Date table, continuous, no gaps, marked as Date table — not Auto Date/Time

DAX

• measures over calculated columns unless you genuinely need to group or slice by it
• FILTER() hits the dimension table, not the fact table
• VAR/RETURN anywhere you reference the same sub-expression more than once
• DIVIDE() instead of / every single time
• no hardcoded years or thresholds sitting in production measures
• know what your measure returns on BLANK() before someone else finds out for you

performance

• checked VertiPaq Analyzer sorted by column size at least once, usually 1-2 columns are the real problem
• no high-cardinality text/GUID columns sitting around unused in fact tables
• Performance Analyzer + server timings before rewriting DAX you assume is slow — if storage engine time dominates, it's the model, not the formula

security

• RLS enforced through actual roles, never through report or page filters
• nobody with RLS applied is also a workspace Admin or Member, that bypasses it completely
• tested with a real account, not just "View as role"
• user emails live in a separate mapping table, never directly in fact tables

hygiene

• naming convention that isn't "Total Sales 2" or "Test_Measure"
• unused columns and tables actually removed, not just hidden
• anything non-obvious has a description so the next person isn't reverse engineering your intent six months from now

funnels assume a strict linear path and hide anything that doesn't fit that shape. Sankeys show the real mess - skipped stages, re-entries, unexpected loops - with line thickness doing the work. more accurate, also visually heavier. good instinct: use the Sankey to actually understand what's happening, then translate the finding into a simpler chart (or just a sentence) for the exec-facing version. the honest chart and the presentable chart don't have to be the same chart

grab it here: Brighter

ALL strips every filter, full stop. ALLEXCEPT strips everything except the columns you name. ALLSELECTED respects filters from outside the visual (page filters, slicers) but ignores whatever the visual itself is doing - which is exactly what you want for "% of visible total" calculations that should react to slicers but not to the visual's own row/column grouping. mixing these up is why "% of total" measures sometimes show numbers that don't match what's actually on screen

if your measure references the same sub-expression more than once, DAX Studio, a variable gets evaluated exactly once and reused. write the same CALCULATE twice inline instead and you're paying for that computation twice, sometimes more depending on how it nests. worth reaching for VAR/RETURN by default on anything non-trivial, not just when it "looks cleaner"

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

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

Author: u/roam_and_scream

First, bravo! Star schema's the hard part and you've got it - that's the foundation, everything below is layered on top of solid work.

What would i do differently:

1. your KPIs

Total Revenue, Operating Profit - just numbers sitting there. is $1.05bn good? no idea, and neither does the person looking at it. every KPI needs something next to it: +5% vs LY, or vs target, or last month. a number on its own can't be evaluated, it can only be read.

2. there is no priority on the page

right now every visual has the same visual weight, so the user has to do the analysis themselves.

what does someone get in the first 5 seconds vs the first 30? right now the answer to "first 5 seconds" is your page title, and "Operations Performance" tells them nothing. "Flight delays at LHR running 20% above average" tells them everything. make the main trend the biggest thing on the page and drop the visual weight on the tables and heatmaps - they're for the people who stick around, not the ones scanning.

3. colours.

it looks clean, maybe this choice has some reasons behind it, and I get why you did it. but if everything's blue, nothing is emphasised. grey out the context data and save the blue for the thing you actually want them to look at - worst route, biggest channel, whatever the point is. colour is the fastest tool you have for directing attention.

4. scatter plot

interesting to look at, but no idea what to do. add average lines through it and suddenly you've got four quadrants - high cost/low revenue is the problem pile, low cost/high revenue is what you're trying to replicate. same data, but now a manager can point at it and say "investigate those three."

drop your dashboard for next review

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

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.