Integrating an LLM with Microsoft Dynamics 365 goes through the Dataverse Web API, which exposes Dynamics entities such as accounts, opportunities and cases over a standard OData interface, or through Power Platform connectors for teams already building on that layer. A custom MCP server wrapping specific Dataverse operations, similar in shape to a Salesforce integration, lets an assistant search records, summarize an account's history or draft a follow-up email, with authentication handled through the same Microsoft Entra ID app registration pattern used for Microsoft 365 and SharePoint integrations, so a single identity and permissions model can cover multiple Microsoft systems. Delegated permissions, where the assistant acts as the signed-in user, keep Dynamics' own security roles and business unit restrictions in force rather than granting the integration broader access than any individual user has. Write operations such as updating an opportunity stage or creating a case should go through the same approval-before-execution pattern used for other CRM and ERP write actions, since Dynamics workflows and validation rules often depend on the sequence in which fields are set. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds these Dataverse connectors as part of broader Microsoft ecosystem integrations spanning 365, SharePoint and Dynamics.
Dataverse is the real integration surface, not "Dynamics" as one thing
Dynamics 365 is a family of applications, sales, customer service, field service, all built on top of Dataverse, and that shared data layer is what an LLM integration actually talks to rather than any single application's user interface. Dataverse exposes its entities, accounts, contacts, opportunities, cases, over a standard OData Web API, and teams already invested in the Power Platform can also reach it through Power Platform connectors. Thinking of the integration target as "Dataverse entities" rather than "Dynamics the app" clarifies which operations are actually available and keeps the design consistent even as different Dynamics applications sit on top of the same data.
Mapping CRM entities to narrow tools
The same principle that applies to Salesforce integrations applies here: expose a small number of purpose-built tools rather than raw entity access.
| Tool | Dataverse entity | Typical operation |
|---|---|---|
get_account_summary | Account | Read, single record by ID |
search_open_opportunities | Opportunity | Read, filtered list with row limit |
summarize_case_history | Case | Read, aggregated over related activities |
update_opportunity_stage | Opportunity | Write, requires approval step |
Each read tool should query through the permissions of the requesting user rather than a shared service identity, and each write tool should route through the same approval-before-execution pattern used across other CRM and ERP write actions. Keep each tool mapped to exactly one entity and one operation rather than one tool trying to cover several Dataverse entities at once.
One identity model across Dynamics, 365, and SharePoint
Authentication runs through Microsoft Entra ID app registration, the same underlying identity platform used for Microsoft 365 and SharePoint integrations, which means a single, well-designed identity and permissions model can cover Dynamics alongside other Microsoft ecosystem systems rather than maintaining separate authentication logic for each. Delegated permissions, where the integration acts as the signed-in user rather than with application-wide access, keep Dynamics' own security roles and business unit restrictions in force exactly as they would be if that user opened the application directly. One Entra ID app registration, reused with delegated permissions across systems, beats maintaining a separate identity model for each Microsoft product.
Why write actions need to respect Dataverse's own sequencing
Dynamics workflows, business process flows, and validation rules often depend on fields being set in a specific order or on certain conditions being true before a transition is valid, for example an opportunity needing particular fields populated before it can move to a closed stage. An LLM-driven write tool that sets fields out of that expected sequence can trigger validation errors or, worse, leave a record in an inconsistent state that Dynamics' own business logic didn't anticipate. Testing write tools against the same validation and workflow rules that apply to manual data entry, not just against the raw API's success response, catches this class of problem before it reaches production.
Frequently asked questions
Does a Dynamics 365 integration need a different identity setup from a Microsoft 365 integration?
No, both typically authenticate through the same Microsoft Entra ID app registration pattern, which is one of the practical advantages of standardizing on Microsoft's ecosystem. A single, carefully scoped app registration with delegated permissions can support Dynamics, SharePoint, and 365 integrations built by the same team.
Can an LLM assistant create or update Dynamics records directly?
It can, but write operations should go through an approval step where a human confirms the specific change before it commits, rather than executing autonomously. This matters especially in Dynamics given how much business logic and workflow validation depends on the exact sequence and combination of field values.
Is Power Automate a better fit than a custom MCP connector for Dynamics?
Power Automate suits triggered, event-based automation well, such as a flow that runs whenever a record changes. A conversational assistant that needs to answer on-demand questions or take context-dependent actions fits a purpose-built connector or MCP server better, since Power Automate isn't designed around a model deciding in real time which action to take.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, builds Dataverse connectors as part of broader Microsoft ecosystem integrations spanning 365, SharePoint, and Dynamics, using one consistent Entra ID identity model across all three. This work mirrors the approach we take for Salesforce integrations and for Microsoft 365 and SharePoint connectors, and follows the same design principles covered in our MCP server primer.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.