Dynamics 365 CRM (Dataverse)

Quick answer

The /crm server connects to any Dataverse environment — Sales, Customer Service or a tenant's own tables — through an administrator's one-time consent, and exposes generic tools (list, describe, query, create, update…) guided by a skill for every table. Where Customer Insights - Journeys is installed, a handful of high-level tools and a business-friendly skill let Claude draft segments and journeys, and publish them after confirmation. Everything is scoped per role, audited and can require approval.

Connecting an environment

Connect with Microsoft (recommended): in the Admin Center, AI & MCP → Dynamics 365 CRM → Connect with Microsoft, a tenant administrator signs in once with their Dynamics 365 administrator account and consents; the callback lists the environments of their Microsoft Entra ID tenant and the administrator picks the one(s) to connect. Plur-e then requests, in the background, a token for the chosen environment with the cached sign-in and creates an application user there — the identity the server uses afterwards, independent of the administrator's own account.

Manual add still works for administrators who prefer it or whose tenant policy blocks the consent screen: enter the environment URL directly under the same page, then create the application user in the Power Platform admin center with the application id the Admin Center shows, and press Verify connection.

Two identity modes, set per connection:

• AppOnly (default) — every call runs as the application user; Dataverse security roles are whatever the administrator assigned to that user.
• AppOnlyImpersonate — the server adds the calling user's Dataverse oid as caller, so their own security roles apply (record ownership, field-level security). Requires the application user to have the Act on Behalf of Another User privilege.

If the silent token request fails (the cached sign-in expired, or the administrator's account lost access to the environment), the Admin Center shows Grant access for that connection to repeat the consent for it specifically, without redoing discovery for the others.

Generic tools

Every table in the connected environment — standard or custom — is reachable through the same small set of tools; a skill (read with crm_get_skill) documents each table's fields, relationships and quirks.

See Business Central mobile flows for the equivalent pattern on the /bc server: skills as authoritative context, { method, parameters } style calls, and posting/publishing warnings kept verbatim.

Customer Insights - Journeys

Where a connected environment has Customer Insights - Journeys installed, the server adds guides under journeys/ (overview, segments, content-and-emails, triggers-and-events, forms-and-consent, analytics) and fact sheets for its tables (entities/msdynmkt_*: journeys, templates, segments, emails, forms, triggers, consent…), on top of the generic tools above. A handful of high-level tools cover the everyday actions without hand-writing OData:

Claude always calls crm_marketing_overview first to check whether the environment has Customer Insights - Journeys before offering journey- or segment-specific actions; on environments without it, only the classic campaign path below applies.

Campaigns

The flows/campaign-management skill is written for a business user, not a developer: it walks Claude through turning a plain-language brief ("email our Texas accounts about the new price list") into an audience, a message and, on Customer Insights - Journeys environments, a journey — or, on tenants without it, a classic campaign (campaign, list, campaignactivity, campaignresponse tables in Dynamics 365 Sales).

What to tell Claude: who the campaign is for (in your own words — an account list, a segment definition, a list of criteria), what to send and through which channel, and when. The skill follows a fixed order so nothing goes out before you have seen it: Claude previews the audience with crm_query against your criteria and shows you who it matches; once you confirm, it calls crm_segment_publish; it then calls crm_segment_members to verify the published segment's actual size before going further; once you confirm again, it drafts the journey with crm_journey_create_from_template and only calls crm_journey_publish after a final confirmation. crm_segment_publish and crm_journey_publish are write tools that a tenant's approval policy can still gate even after you confirm in the conversation. The Plur-e Plugin ships a dedicated /plure-campaign <brief> command that follows this skill end to end.

Scopes and approvals

Tool scopes follow the same model as /bc: every tool is read or write; read is enabled by default for every role, write is None until a tenant administrator grants it per role (AI & MCP → Scopes). The generic write tools (crm_create_record, crm_update_record, …) and the Customer Insights - Journeys publish tools can additionally require administrator approval or a client-side confirmation prompt, per the tenant's write policy — see MCP security model.

Limits and what is not covered

• Analytics are not exposed as rows. Customer Insights - Journeys keeps engagement metrics (opens, clicks, conversions) in an analytics store outside the standard Dataverse Web API; crm_marketing_overview and the journeys/analytics guide summarise what is reachable, but there is no crm_query equivalent for raw event-level analytics.
• Outbound marketing (the legacy app) is retired by Microsoft; the skills and tools target Customer Insights - Journeys (real-time journeys) and classic Sales campaigns only.
• crm_execute_action only runs actions and functions on an explicit allow-list; a custom plugin action that is not on it is not reachable until Plur-e adds it.
• Per-connection Delegated (on-behalf-of) access is on the roadmap; today every call is AppOnly or AppOnlyImpersonate.

Related: Connect Claude · Tenant memory · Security model · Product page