Semantic Model Foundations - Giving Copilot A Fighting Chance

When I built my first Power BI semantic model, I had dreams of elegantly slicing sales data by product, region and date with silky-smooth visuals and dazzling insights. What I ended up with was a tangled mess of cross-directional relationships and a series of error messages that might as well have been laughing at me. I still remember sitting there, eyes twitching, watching another circular dependency warning flash up on the screen, wondering if this was some form of BI purgatory. If Copilot had been around then, I imagine it would have thrown its virtual hands in the air and walked away.

That painful experience taught me one of the most important lessons in Power BI development. Good models are not just for performance. They’re for keeping your sanity.

And now, with AI tools like Copilot helping users query datasets in natural language, clean design isn’t just helpful for you, it’s critical for the machine too. Many of the best practices that were once championed to help human analysts understand the data model also happen to be exactly what Copilot needs to perform well. It’s almost like someone designed these things with intelligence in mind.

So, before we get carried away building Verified Answers, writing AI Instructions, or summoning narrative summaries like modern-day oracles, we need to talk foundations. This article walks through the boring, beautiful basics of semantic model hygiene.

Build a Star, Not a Spaghetti Bowl

Power BI performs best with a dimensional model. This usually means a central fact table (like Sales) connected to related dimension tables (like Product, Customer, Date). Keep the relationships clean and directional, typically from dimension to fact.

You can try to get clever with snowflakes or multi-hop relationships, but in the end, you’ll just make life harder for yourself and for Copilot. Simplicity wins so stick with predictable structure. If the model looks like it belongs in a crime investigation corkboard, it probably needs a rethink.

Name It Like You Mean It

Let’s be honest, most users aren’t thrilled by column names like ‘qty_sld’ or ‘cust_typ_cd’. Neither is Copilot. It doesn’t do well with cryptic abbreviations or internal shorthand. Rename your fields and tables with clear, friendly names. Think: ‘Units Sold’, not ‘qty_sld’. ‘Customer Type’, not ‘cust_typ_cd’.

The person using your report won’t have to mentally decode it every time too, so clarity helps everyone! And when Copilot is interpreting natural language questions, it increases the chance of a correct match. You don’t want the AI to misinterpret ‘Product Class’ as a university course offering.

Set Data Types and Summarisation Rules

There’s nothing worse than a report showing the sum of product IDs. Except maybe Copilot doing it for you.

Go through your columns and set the data types correctly. Mark columns like IDs or category labels as ‘Do not summarise’. Otherwise the system might default to aggregating them leading to some very strange visuals, baffled users, and even the dreaded AI hallucinations.

Next double-check that your dates are actual date types. I’ve seen all sorts over the years, it’s like someone gave the calendar to a time-travelling poet. We’re talking month names stored as text, fiscal years as strings, and timelines that make no chronological sense.

These settings can be updated from the ribbon in desktop while in the reporting view like so:

or from the model view:

Write Your Measures Explicitly

I know it’s tempting, but stop dragging columns into visuals and letting Power BI guess what you want. For Copilot to understand what ‘Revenue’ or ‘Growth’ means, you need to define them with explicit DAX measures.

Use consistent naming conventions (‘Total Sales’, ‘YoY Growth’, etc.) and avoid calculated columns unless you need them. This helps both human users and AI reason from the same foundation. You’re teaching your Copilot the words it can use in a sentence so think of these measures as your core vocabulary and stick to it!

Tame Your Relationships

My first model was a masterclass in relationship chaos, I was young and full of inner joins. Now I stick to single-direction, one-to-many relationships wherever possible. It’s not just a performance thing, it’s a comprehension thing.

Copilot relies on the model to understand how things connect. If your relationships are ambiguous or bi-directional in all directions, you’re basically throwing the AI into a logic puzzle and hoping it finds its way out.

Add Metadata (Yes, the Paperwork)

I know. No one gets into BI because they love filling in field descriptions. But it matters. A lot. Especially if you want to get the most out of Copilot.

I’ve worked with developers who will spend hours tweaking the exact shade of a visual gradient but leave half the fields in their model without descriptions. It’s the classic human aversion to doing the paperwork. We’d rather be building something that looks cool than documenting something that’s vital.

Copilot actually reads your field descriptions. It uses them to understand what a column or measure is about. You don’t need an essay. Just a clear, human-readable sentence. For example: “Total Sales is the sum of order amounts from the Sales table.” That’s all it takes to give the AI a fighting chance.

You can update your model table and field descriptions in the model view of Power BI Desktop:

In the new ‘Prep Data for AI’ experience, Copilot can even suggest descriptions for your tables/fields. That means instead of wrestling with documentation, you can use AI to kickstart the text—then polish it. That small extra step dramatically boosts how clearly Copilot understands your model.

Don’t Mix Layers

Finally, be cautious about exposing too many raw data prep fields in the semantic model. Users don’t need to see your staging logic, and Copilot certainly doesn’t need to stumble into your debugging columns. Keep your model clean and presentation-ready. Think of it as the front of house, not the kitchen.

Final Thoughts

Your semantic model is the nervous system of your Power BI solution. It holds the relationships, the business logic, the definitions, the vocabulary. If it’s a mess, everything built on top of it – visuals, narratives, Copilot responses – will be messy too.

The irony is that we’ve known many of these best practices for years. They weren’t invented for AI. They were invented for humans. Now we have AI trying to use the same model, thankfully those same human-first practices turn out to be AI-first too.

So give your Copilot a clean cockpit. Lay out the dashboard controls, label everything clearly. And for the love of data, don’t make it fly blind through a tangle of bidirectional logic and ambiguous column names.

It’s not glamorous work. It’s the behind-the-scenes stuff. But like all good foundations, it’s what keeps the whole thing standing when the questions start flying in.

This is the first article in an ongoing series on building AI-Ready Semantic Models for Power BI Copilot. Over time, I’ll update each article with a contents section linking to the full series so you can follow along or jump to the topic most relevant to you.