Getting a Power BI semantic model ready for Copilot

The pattern is consistent enough that we can usually predict it before opening the file.

Copilot gets switched on. There is a burst of enthusiasm. Within about six weeks usage is down to a handful of people, and the internal verdict is that it is not very good yet.

Then you open the semantic model and find columns named Column1, no descriptions, four date columns and no marked date table, measures written inside visuals, and bi-directional relationships added at some point to make one chart work.

Copilot did not fail. It was asked to reason about a model that a new analyst would also struggle with, except the analyst would ask someone.

The preparation checklist#

This is roughly the order we work through it.

1. One model, not forty datasets#

If the same business concept is defined in six datasets, Copilot will answer differently depending on which one it is pointed at, and users will conclude it is unreliable. They will be right.

Consolidate to a governed model per business domain before anything else. This is usually the largest piece of work and the one with the longest payoff, Copilot or not.

2. Star schema, properly#

Copilot navigates relationships. A wide flat table or a snowflake with ambiguous paths gives it more ways to be wrong.

• Conformed dimensions, fact tables at a declared grain
• No bi-directional relationships unless you can articulate exactly why
• Inactive relationships removed rather than left lying around
• A marked date table with a contiguous date range and the hierarchies you actually use

3. Names a human would use#

Rename everything to the word the business says out loud. CustID becomes Customer ID. amt_disb_eur becomes Disbursed Amount. Hide technical columns — keys, surrogates, staging fields — from the model view entirely.

If a column is hidden, Copilot will not offer it. That is usually what you want. Curation improves answers more than completeness does.

4. Descriptions on everything that matters#

This is the highest-leverage step and the one most often skipped.

Every table, column and measure gets a description written as a plain sentence stating what it is and what it excludes. Not Active customers but Customers with at least one contract in status 3 or 4 as at the report date; excludes staff and test accounts.

The model reads these literally. A description that names the exclusion removes an entire class of wrong answer.

5. Synonyms#

Under the model's linguistic settings, add the words your business actually uses. Clients, borrowers, accounts and members may all mean the same table. Approval, acceptance and conversion may all mean the same measure. Every synonym you add is a question that now works instead of failing.

Do this with a real user in the room. You will not guess their vocabulary.

6. Measures on the model, never in the visual#

Any calculation defined inside a report page is invisible to Copilot. If a number matters, it is a measure on the model with a description and a format string.

Format strings matter more than they look — a percentage that renders as 0.4213 in a generated answer reads as broken even when it is correct.

7. Verified answers for the questions that count#

For the questions where being wrong is expensive — the board metrics, the regulatory figures — configure verified answers so the assistant returns a known-correct, pre-approved response rather than reasoning its way there.

Pick these from your actual top questions, not from a list of what sounds important.

8. Row-level security, tested through the assistant#

Whatever RLS applies in the report must apply in the AI answer. Test it as a restricted user, in the assistant, not just in the report. This is the one item on this list where the failure mode is a data breach rather than a bad number.

9. Performance#

Copilot answers are queries. A slow model produces slow answers and, past a few seconds, people stop asking.

The usual suspects: high-cardinality columns kept for no reason, datetime columns that should be split into date and time, calculated columns doing work that belongs upstream in dbt or in the source, and DirectQuery used where import would do.

Then score it#

Preparation is not finished when the checklist is done. It is finished when you can measure it.

Build a set of fifty questions your business genuinely asks. Write the correct answer for each. Run them, score them, and keep the score.

That gives you three things you cannot get any other way: a number to improve, evidence when someone claims it is useless, and an alarm when a model change breaks something that used to work.

Re-run it whenever the semantic model changes, and expect surprises. Renaming a column can move accuracy several points in either direction.

What to tell the business#

Two things, before you launch rather than after.

What it is good at. Aggregations, comparisons, trends and slicing over the metrics you have defined. That covers a large share of what people ask.

What it will refuse. Anything not in the model. Say this out loud, and configure it to refuse rather than improvise. A tool that says "I do not have that" keeps its credibility. A tool that invents keeps nothing.

The organisations getting real value from Copilot are not the ones that switched it on earliest. They are the ones that spent six weeks on the model first and launched to a business that knew what to expect.