Microsoft Fabric
A new category inside SqlDBM, starting with Copilot V1.
For the past year, we’ve been asking a single question: what would AI look like if it were built for the way enterprise data teams actually work?
Not AI bolted onto a modeling tool. Not a generic chatbot that happens to live in a data product. But an AI experience shaped by the roles, permissions, and governance expectations that enterprise data organizations already operate within.
Because most AI tools today ignore those constraints.
They assume a single user. They operate without shared definitions. They don’t account for how meaning shifts across teams. The result is an experience that works in isolation, but breaks down in real environments—where context, consistency, and control matter.
Today, we’re introducing the answer.
It’s called AI Experience, and it’s a new pillar of the SqlDBM platform.
AI Experience defines how AI operates across data modeling from design to governance to consumption. It is the foundation layer for bringing AI into structured, governed data environments, where context and permissions already exist.
The first release under AI Experience is AI Copilot (Copilot V1), now live for enterprise customers.
Here’s what’s in it, and why each piece matters.
Role-aware Copilot across six roles
Data teams are not monolithic. A data modeler exploring a new schema has a very different job than an analytics engineer validating dbt transformations, and neither of them has the same needs as a business stakeholder consuming the model as documentation.
Most AI tools flatten those differences. They provide the same interface, the same assumptions, and the same responses regardless of who is using them.
Copilot recognizes this.
The assistant adapts to six distinct roles including Modeler, Consumer, Analytics Engineer, and others, and the behavior shifts accordingly. A Consumer sees a Copilot that helps them explore and understand a model. A Modeler sees one that can help design and refactor it. An Analytics Engineer gets prompts and context relevant to dbt workflows.
This means every user in your organization gets an experience tailored to what they actually do, without administrators having to build custom configurations for each team.
More importantly, it ensures that AI outputs are grounded in the context of the user’s role—not treated as universally applicable answers.
Conversation history, with control that belongs to you
AI assistants without memory feel broken. You ask a question, get an answer, then ask a follow-up, and the context is gone.
In practice, that breaks real workflows. Teams repeat questions, lose continuity, and can’t build on prior decisions.
Copilot saves conversation history per project. Your team can pick up where they left off, reference earlier answers, and build on previous context across sessions. Conversations are scoped to the project they belong to, so there is no leakage between workstreams.
For organizations that need tighter control, admins have a single account-level toggle to disable conversation history. When disabled, history stops saving immediately and any existing history is removed. When enabled, conversations save from that point forward. The toggle is on by default, because most teams benefit from it, but the choice is yours.
This balance—continuity with control—is what allows AI to fit into governed environments rather than working around them.
Role-specific pre-prompts for faster time-to-value
Getting useful output from an AI assistant often depends on knowing what to ask. For new users, that’s a barrier.
Copilot ships with role-specific pre-prompts. When a user opens Copilot for the first time in a session, they see suggested prompts relevant to their role. A Modeler sees prompts about designing tables, managing relationships, and refactoring schemas. An Analytics Engineer sees prompts about dbt models, test coverage, and documentation. A Consumer sees prompts about understanding what a model does and how to query it.
Users can still type anything they want. The pre-prompts are there to shorten the path from “I just opened this” to “I got a useful answer.”
In most cases, that happens in the first interaction, reducing the friction that often prevents AI tools from being adopted beyond initial experimentation.
AI Copilot for database documentation
Documentation is the part of data modeling that most teams know they should do, and most teams don’t.
The issue is not awareness. It’s that documentation sits outside the workflow, so it gets deprioritized.
Copilot addresses this directly.
On any database documentation view, you can generate descriptions for tables and columns with a single action. You can ask column-level questions and get answers grounded in the actual project context, not generic explanations. And when you find something worth keeping, the generated insight saves back to the model itself, so the documentation becomes a permanent part of your modeling artifact.
This is how documentation stops being a side project and becomes part of the modeling workflow, accumulating naturally as teams work, rather than requiring separate effort.
Admin permissions console, with governance by design
Enterprise AI adoption lives or dies by the controls available to administrators. It’s the first question that comes up in any enterprise evaluation, and it should be.
AI Experience includes a dedicated admin permissions console. Admins can enable or disable AI access on a per-user basis. User status is exportable to XLSX, so compliance and governance teams have an audit-ready record of who has access. New users default to AI off, meaning organizations can phase in adoption deliberately rather than having to actively remove access from accounts that shouldn’t have it.
Admins cannot accidentally lock themselves out. The counter updates live. The system is designed to give governance teams the clarity they need to sign off on AI access with confidence.
This is not governance layered on top of AI. It is part of the system itself that ensures that AI can be adopted without breaking existing controls.
Why this matters: AI Experience is a platform, not a feature
Copilot is the first piece of AI Experience, not the last.
What we’re introducing today is the foundation for how AI shows up across the SqlDBM platform. The same principles—role-awareness, governance, and alignment to how enterprise teams already operate—will apply across future capabilities.
Most AI tools operate on top of data systems, without access to consistent definitions, relationships, or permissions. In those environments, outputs depend on pattern matching rather than understanding.
AI Experience operates inside the data model itself where structure, meaning, and governance already exist.
That difference determines whether AI produces useful results or unreliable ones.
What’s next
The next step expands AI Experience beyond the SqlDBM user interface.
In May, we’ll release our MCP Server — a new surface that makes SqlDBM accessible to every AI tool and agent in your organization. This extends AI Experience beyond a single interface and into the broader ecosystem where teams are already working.
More on that soon.
Get started
For now, if you’re a SqlDBM enterprise customer, AI Copilot V1 is live in your environment.
Reach out to your account team to enable it for your organization, or contact us to learn more about AI Experience.
Final thought
AI systems don’t fail because they lack intelligence.
They fail because they lack context.
Without shared definitions, structured models, and governance, AI systems guess.
With the right foundation, they don’t have to.
AI Experience is that foundation.