But the new roadmap item’s framing needs scrutiny. Microsoft’s own product record shows that Dataverse tables have already been available as a Copilot Studio knowledge source for more than a year. The company’s 2025 release-plan entry says the capability entered public preview on May 23, 2024 and reached general availability on May 22, 2025. Current Copilot Studio documentation also instructs makers to select Dataverse from the Add knowledge workflow and add up to 15 tables to a knowledge source.
In other words, Roadmap ID 568929 should not be read as the debut of Dataverse-backed grounding in Copilot Studio. Microsoft has not published technical release notes explaining what separates this August preview and September rollout from the existing generally available feature. The most defensible reading is that the company is tracking a further integration or revised implementation under a broad description that sounds like a new launch.
For IT teams, that ambiguity is more than a wording problem. Anyone postponing a Dataverse-grounded agent project until September may be waiting for functionality Microsoft already documents as available. Anyone who has already deployed it should not assume the roadmap entry promises an automatic upgrade, expanded data scope, or a change in licensing or permissions. None of those details appears in the roadmap listing.
The feature already exists, with firm prerequisites
Microsoft Learn’s Copilot Studio documentation describes Dataverse tables as an internal knowledge source that connects to a configured Dataverse environment and uses retrieval-augmented generation to return answers. A user asks a natural-language question, Copilot Studio retrieves relevant table data, and the model uses that material to formulate the response.
That is materially different from an agent action. An action typically calls a flow, connector, or API to perform a defined operation or fetch a specific result at run time. A Dataverse knowledge source is intended to support conversational retrieval across selected tables. It is designed for questions such as asking a sales agent about open opportunities, a service agent about case patterns, or an operations agent about records maintained through a model-driven Power App.
Microsoft’s current setup requirements impose boundaries that should shape deployment plans:
- Dataverse Search must be enabled in the environment before tables can be added as a knowledge source.
- The agent must use the “Authenticate with Microsoft” option; anonymous agents and manually authenticated agents are not supported for this source.
- Makers need sufficient access to the underlying Dataverse data before a table will even be visible for selection.
- In classic orchestration, an agent can use two Dataverse knowledge sources, each covering up to 15 tables. Microsoft lists no table-count cap for Dataverse in generative orchestration.
Those constraints mean that this is not a mechanism for safely turning a public website chatbot loose on customer or employee data. The agent’s retrieval model is tied to Microsoft Entra ID authentication and the user’s available access. Microsoft says a user querying an agent should only receive knowledge-source content that the user can access.
That permission model is the central operational safeguard, but it also shifts responsibility to the tenant. If an employee can already read a Dataverse record, an agent grounded in that table can potentially make that data easier to discover and summarize. Copilot Studio does not repair an overly broad Dataverse security role; it can make the consequence of that role more conversational.
Search configuration is part of the rollout, whether the roadmap says so or not
The unspoken dependency in the roadmap item is Dataverse Search. Microsoft’s documentation is explicit: a Copilot Studio agent cannot use Dataverse tables as a knowledge source unless Dataverse Search is enabled. In production environments, Microsoft says that enabling the service indexes Dataverse data so it becomes searchable; with the default setting used by sandbox, trial, developer, and Dataverse for Teams environments, indexing occurs when a generative-AI experience triggers it.
This matters for administrators because a “native knowledge source” description may suggest a simple switch inside Copilot Studio. The actual readiness work spans Power Platform administration, table design, security roles, and search configuration. A Copilot Studio maker may be able to build the agent interface, but an environment administrator can still block deployment by leaving Dataverse Search disabled or by withholding table permissions.
Microsoft’s documentation also indicates that table metadata affects response quality. Makers can attach synonyms and glossary definitions to tables and columns so the orchestration layer can interpret organization-specific terminology. That is especially important with custom schemas, where a field name may be meaningful to an app builder but opaque to an AI model or end user.
A column called
cr_123_abc, for example, may contain a flight identifier, service tier, regional code, or internal customer classification. If the agent has no descriptive metadata, it has less basis to map a user’s plain-language question to the correct field. The hard part of a Dataverse knowledge deployment is therefore not connecting the table. It is selecting the right tables, excluding fields that should not be conversationally discoverable, and documenting the vocabulary the agent needs to understand.
File and long-text support still carries a preview warning
Microsoft’s current documentation adds another important distinction: using unstructured reasoning over Dataverse Multiline Text and File columns remains labeled as preview. That capability can improve responses from memo fields and file attachments, but it requires administrators and makers to configure the relevant columns as searchable in Power Apps and include them in the table’s Quick Find view.
Microsoft warns that creating a search index can incur additional Dataverse capacity costs. It also lists several limitations for the preview path, including unsupported non-organization-based languages in file attachments and restricted support for virtual tables. If a Dataverse knowledge source is added before the required long-text or file fields are configured, Microsoft says the system can take up to two days to backfill the request, though re-adding the source may accelerate the process.
This is where the September general-availability date deserves restraint. The 568929 roadmap entry does not say whether it is meant to graduate that unstructured-file capability, expand generative orchestration support, revise indexing behavior, or simply reannounce Dataverse grounding for a new Copilot Studio experience. Microsoft has not tied the entry to the long-text and file preview documentation.
Administrators should therefore treat the August and September milestones as a reason to monitor the feature, not as confirmation that every Dataverse content type is production-ready. Structured table retrieval is documented today. Semantic use of attachments and richer text fields has more caveats.
The cost conversation extends beyond agent usage
The roadmap entry does not disclose pricing, capacity impact, or whether the new integration changes Copilot Studio credit consumption. Microsoft’s March 2026 Copilot Studio Licensing Guide provides some useful baseline context but does not attach a special price to Dataverse knowledge grounding.
The guide says a tenant with a Copilot Studio license receives default Dataverse capacity of 15 GB for database storage, 20 GB for file storage, and 2 GB for log storage. It also warns that capacity is pooled at the tenant level and that additional subscriptions do not add another allocation of those default amounts. Organizations that ingest files, expand table storage, or enable indexing across large data sets need to watch both their Dataverse capacity and their separate Copilot Studio usage commitments.
This is particularly relevant for Dynamics 365 deployments. The value proposition of Dataverse grounding is that an agent can speak over business data already used by sales, service, field operations, or custom Power Apps. The risk is that an AI project becomes the first workload to expose poor capacity planning, loose table security, undocumented custom fields, or stale data-retention practices.
The roadmap record lists Worldwide Standard Multi-Tenant as the cloud instance and names web as the platform. It does not mention government clouds, sovereign environments, regional exceptions, or a migration path for organizations already using Dataverse as a Copilot Studio knowledge source. Those omissions matter because Copilot Studio availability and generative-AI features are often more constrained than the underlying Dataverse platform.
What teams should do before September
Organizations do not need to wait for Roadmap ID 568929 to determine whether Dataverse grounding fits their agents. They should first inventory the tables an agent would need, review the security roles assigned to intended users, and confirm that Dataverse Search is enabled in the target environment. Then they should test a small set of questions against known records, including questions that must not return restricted information.
They should also decide whether the use case calls for knowledge retrieval or an action. A policy or account-summary agent may work well with Dataverse as knowledge. An agent that must create a case, modify an opportunity, approve an expense, or run a controlled transaction still needs a governed action path with explicit authorization and auditability.
The September date is best treated as a roadmap checkpoint, not a deployment prerequisite. Microsoft has documented Dataverse table grounding as generally available since May 2025; what remains unresolved is what, precisely, the new roadmap item adds. Until Microsoft publishes release notes that identify the delta, existing customers should validate their current configuration rather than plan around a feature they may already have.
