Microsoft recently announced at FabCon that Copilot will soon be available across all SKUs, a major step toward making AI-powered analytics accessible to everyone. With this exciting shift, a critical question now sits in front of every data team:
Is your semantic model ready for Copilot?
While the idea of simply “asking your data questions” sounds futuristic, the reality is that Copilot’s effectiveness hinges entirely on how well your semantic model is designed. Copilot reads structure, logic, metadata, and context. A strong, AI-ready model ensures that Copilot delivers accurate, insightful, and relevant answers without misinterpretation or confusion. In this post, I’ll break down official Microsoft recommendations and share some thoughts on what makes a semantic model Copilot-ready. If you’re preparing to bring AI into the hands of more users, start here.
Table Linking and Relationship Types: Build a Logical Framework
Every strong model starts with solid relationships. Without clearly defined links between tables, Copilot is left guessing.
Start by explicitly defining relationships using the correct cardinality:
- One-to-many for classic fact-to-dimension joins
- Many-to-many where necessary (though best avoided when possible)
- Active vs. inactive relationships clearly labeled for DAX clarity
Think of relationships as the model’s roadmap. If it’s vague or missing, knowing where to go can be confusing.
Fact and Dimension Tables: Structure for Context and Clarity
To help Copilot understand your data’s meaning, maintain a clean separation between fact tables and dimension tables.
- Fact tables might contain transactional data like Online Purchases, Employee Attendance, or Shipment Logs
- Dimension tables could describe those facts with tables like Customer Profiles, Store Locations, or Package Types
The best structure for Copilot is a star schema. It’s simple, performant, and easier for Copilot to navigate when building natural language reports.
Measures: Standardize, Name, and Predefine
Copilot is most powerful when working with clear, ready-to-use measures. That means it’s on us to ensure the foundational logic is strong.
- Standardized Logic: Measures should follow logic that’s easy to explain.
- Intuitive Naming: Choose names that convey purpose. For instance, Net_Promoter_Score is much clearer than NPS_Val.
- Predefined Measures: Include commonly used metrics like Weekly Active Members, Email Engagement Rate, or Support Case Resolution %, these are the building blocks Copilot will reach for first.
When using Copilot, the best experience comes from giving it high-quality ingredients to start with.
Hierarchies: Enable Natural Drilldowns
One of the great things about Copilot is its ability to guide users through layered insights. But it needs help knowing what those layers are.
Create logical hierarchies in your dimension tables—for example:
- Marketing Campaigns: Campaign Year > Quarter > Channel > Subchannel
- Manufacturing: Product Line > Category > Material > Component
Well-defined hierarchies help Copilot answer questions like “Show production by material for last quarter” with more depth and confidence.
Column Naming and Data Types: Clarity is Key
Your column names should speak for themselves. If a name requires internal documentation to understand, it may be difficult for Copilot to comprehend it..
- Avoid coded labels like CL_ID or ACT_TYP_CD
- Use clear, natural names like Client Identifier or Activity Type
Equally important: data types must be accurate and consistent. For example, if your “Invoice Total” column is stored as text, Copilot will struggle to make calculations using it.
Standardize Column Values
Even if your schema is pristine, inconsistent data values can throw Copilot off.
Imagine a “Priority” column with values like High, hi, 1, and Urgent. These inconsistencies confuse both filters and natural language queries. Clean, standardized values such as Low, Medium, High, and Critical, make filtering and summarizing reliable for Copilot and your end users.
Descriptions: Communicate Intent with Metadata
Metadata is how Copilot understands your intentions.
- Add clear, concise descriptions to every table, column, and measure
- Focus on what the field is and how it should be used
- For example, a Subscription Renewal Rate measure might have a description like:
“Percentage of customers who renewed their subscription within the same billing cycle.”
- For example, a Subscription Renewal Rate measure might have a description like:
- For calculation groups, use the description field on the group column to explain the use of the items
Keep in mind: Only the first 200 characters of the description are read by Copilot.
This step is often skipped in the development rush, but it’s one of the most impactful ways to guide Copilot’s behavior.
Key Performance Indicators (KPIs): Define What Matters
Predefining KPIs ensures Copilot has context for what’s truly important to the business.
Instead of making users request calculations like “website bounce rate” or “average delivery time,” have those metrics ready in the model.
When these are present and well-labeled, Copilot becomes far more useful in real business conversations.
Security: Define Role-Level Access
Security is still critical, especially in an AI-first environment. Role-level security (RLS) should be implemented thoughtfully to ensure Copilot doesn’t surface data a user isn’t supposed to see.
By enforcing these boundaries in your model, you allow Copilot to function within your organization’s governance guardrails, without accidental exposure.
Conclusion: Strong Models, Smarter AI
Copilot is an exciting leap forward in making analytics more accessible. But like any AI tool, it’s only as good as the foundation it’s built on.
That foundation is your semantic model. Clean structures, descriptive metadata, intuitive measures, and clear relationships all add up to an experience where Copilot doesn’t just work, it works well.
Start optimizing now. AI is ready, make sure your data is too.