The Sales Close Agent Retirement Isn’t a Feature Swap. It’s a Platform Move.

Solution architect reviewing AI sales agent configuration dashboards on a dual-monitor workstation

A Dynamics 365 Sales architect who spent March configuring the Sales Close Agent for a client’s inside sales team is about to find out that work has an expiration date. September 30, 2026 is the last day anyone can stand up a new instance of the agent. October 30 is the day every existing instance, configured playbooks and all, gets pulled from every environment where it runs. Neither date has gotten much attention outside Microsoft’s own deprecation notes, and the Sales Close Agent retirement comes with a single sentence of guidance: create an instance of Sales Development Agent instead. For a solution architect who built engagement rules, email cadences and knowledge sources around the old agent, that sentence undersells how different the replacement actually is.

Solution architect reviewing sales automation agent configuration on a dual-monitor workstation

What the Sales Close Agent actually does today

Sales Close Agent, still labeled a production-ready preview, was built to run high-velocity, low-complexity deals without a seller touching them until something goes wrong. It works against accounts, contacts, leads and opportunities that match target-customer criteria an admin defines during setup, then sends templated outreach email pulled together from a configured profile, product catalog and a set of knowledge sources. Everything about the agent lives inside Dataverse and Copilot Studio: admins configure it through a settings page inside the Sales Hub, security is granted through custom or out-of-the-box Salesperson roles, and every run is tracked as a record in the msdyn_salesagentrun entity, filterable by status (active, completed, failure) and viewable through standard model-driven views like “Opportunities from Sales Close Agent.”

The mechanics underneath are more rigid than most admins expect once they read past the marketing description. The agent caps outreach at 20 emails per ten-minute window, specifically to control AI credit consumption rather than deliverability. Follow-up cadence is fixed at up to four emails over three weeks and isn’t configurable without a support ticket to Microsoft. If a customer goes quiet, the agent auto-closes the record as lost; if it detects an objection past its comfort level, it escalates to a human seller with full interaction history attached to the record’s timeline. None of that is unreasonable for a first-generation automation feature. It’s also all going away in a matter of weeks, and unlike most Dynamics 365 retirements, this one comes with no in-product migration wizard.

The Sales Close Agent retirement doesn’t come with a migration path

Sales Development Agent, the named successor, doesn’t live in Dynamics 365 Sales at all. It’s a Microsoft Agent 365 offering, deployed and configured from inside Microsoft Teams, currently gated behind the Frontier preview program and requiring an organization to have opted into Microsoft 365’s Targeted Release track for the relevant users, or the whole tenant. That single prerequisite is worth checking before anything else, because an architect who assumes the replacement will simply appear in the Power Platform admin center the way Sales Close Agent did will instead find nothing there to configure. The agent is deployed from the Teams Store or the Microsoft 365 Copilot agent store, and every bit of its setup happens conversationally: you tell it, in a Teams chat, to define a playbook, share sample emails so it can match your tone, upload product documentation as PDFs or Office files, and set a send window such as weekdays between nine and five Pacific.

That configuration model is a real structural difference, not just a change of interface. Sales Close Agent’s behavior comes from admin console pages: profile, product details, target customers, email delivery, email content, knowledge sources, each with its own screen and its own “avoid edits after publishing” warning. Sales Development Agent’s behavior comes from four looser components (playbook, guidelines, product knowledge, and settings) assembled through natural-language instructions inside a chat thread, then validated by uploading a test prospect list and running simulated conversations before typing “go live.” An architecture team used to documenting agent configuration as a set of screenshots from admin pages will need a different documentation approach entirely, since there’s no settings UI to screenshot.

Reconnecting it to Dynamics 365 isn’t automatic either

If Dynamics 365 is the system of record, Sales Development Agent doesn’t sync with it by default. Connecting the two is an explicit, multi-step process: assign the agent a Sales license in the Microsoft 365 admin center, add it to the Dynamics 365 Sales instance with a Salesperson role through the Power Platform admin center, enable the Dataverse Model Context Protocol server in that environment, publish that MCP server using VS Code or the Agent 365 CLI, and then wait for a Global Administrator or AI Administrator to approve the resulting server request before the agent can pull prospect lists from Dataverse or write engagement history back to lead records. That approval step alone means CRM integration for the new agent isn’t something a Sales Hub admin can finish alone; it requires a security decision from someone with tenant-level access, on a timeline that doesn’t care whether your old agent is a week from deletion.

Team collaborating around a Teams-based AI agent configuration screen with sales pipeline data

What this means for a migration plan

Treat this less like a version upgrade and more like standing up a new integration on a deadline. There is no data or configuration carryover: target-customer criteria, product catalog mappings and knowledge source references built into Sales Close Agent don’t transfer, because the two agents don’t share a configuration schema. Prospect data for the new agent needs to arrive as a CSV or Excel file with specific column requirements (email, company name, product, first name, with optional language and country columns for its 22 supported languages), which is a different intake format than anything the old agent’s target-customer configuration expected. And because the replacement currently sits behind Frontier and Targeted Release enrollment, the realistic first step for most teams isn’t configuration at all, it’s confirming with the Microsoft 365 admin whether that enrollment exists yet, since a tenant that isn’t enrolled has no path to the replacement on October 30 regardless of how well the rest of the migration is planned.

Worth flagging to any CFO or IT Director signing off on this work: Sales Development Agent, as documented today, runs without a per-action approval step once it’s live, replies only to email threads it personally started, and has no visual reporting dashboard, with campaign and prospect summaries delivered as answers inside a Teams chat instead. None of those are dealbreakers for a lead-qualification workflow, but they are a materially different governance posture than a Dataverse-native agent whose every run is a queryable, reportable Dataverse record. A rollback plan matters here in a way it usually wouldn’t for a routine feature update, since the source system disappears on a fixed date whether or not the destination is ready.

The narrow window that actually matters

Ten days separates today from the last date to create a new Sales Close Agent instance, and forty days separates it from the date every existing instance disappears regardless of migration status. Neither Microsoft’s release-plan entry nor its deprecation notice describes a bridge between the two agents beyond that single line of guidance, which leaves the actual migration work, mapping old configuration intent to new playbook language, resolving the Frontier and Targeted Release prerequisite, and running the MCP server approval chain, entirely on the implementation team. Routeget Technologies has walked several clients through comparable agent-to-agent platform moves inside the Dynamics 365 ecosystem this year, and the pattern holds here too: the teams that treat this as infrastructure work, with its own project plan and its own risk review, come through it in better shape than the teams who wait for the in-product banner to remind them.

#SalesCloseAgent #SalesAIAgents #Agent365 #CRMGovernance #AgentMigration #DataverseMCP

The Dynamics 365 Sales MCP Server Isn’t the Whole Picture

Solution architect reviewing a Dynamics 365 Sales AI agent integration architecture diagram on a monitor

A solution architect on a recent Dynamics 365 Sales engagement did what the documentation told him to do: he pointed a GitHub Copilot session in VS Code at the newly GA’d Dynamics 365 Sales MCP server, asked it to pull up a stalled opportunity, and watched it come back with a clean summary and a suggested outreach email. Then he asked it to update the opportunity’s close date. Nothing happened. No error, no record change, just a polite explanation that the tool wasn’t available. He had connected the right server. He just hadn’t connected both of them.

That gap trips up more than one team standing up agent access to Dynamics 365 Sales for the first time, because the Dynamics 365 Sales MCP server, which reached general availability in February 2026 after a preview that started in mid-2025, was never designed to be the only door into the system. It is a purpose-built layer that exposes a narrow set of sales-specific actions: retrieving a lead summary, qualifying a lead into an opportunity, generating an outreach email, listing leads assigned to a seller. Anything that looks like ordinary create, read, update, or delete work against Dataverse records sits behind a separate, general-purpose Dataverse MCP server. Architecting AI access to Sales properly means treating these as two components of one system, not as interchangeable options.

What the Dynamics 365 Sales MCP server actually exposes

The Sales MCP server groups its tools into three functional clusters that mirror existing Copilot experiences inside the app: Sales Qualification Agent tools, Sales Opportunity Agent tools, and the broader Copilot in Sales tool set. In practice this means an MCP client authenticated against this server can list a seller’s leads, pull a structured summary of a specific lead or opportunity, move a qualified lead into an opportunity record, and draft or send an outreach email using the same generative logic that powers Copilot inside the Sales workspace. These are opinionated, workflow-shaped actions. They encode the same business rules a seller would hit clicking through the UI, which is exactly the point: an external agent gets sales-process guardrails for free instead of raw table access.

What it deliberately does not expose is a general write path. There is no “update any field on any opportunity” tool here, and that is not an oversight so much as a design choice that keeps the blast radius of an agent request contained to well-understood sales actions.

Where Dataverse MCP fills the gap

For anything outside that workflow shape, whether it’s a custom Power Apps process reading a related quote table or an agent that needs to write directly to a Dataverse entity, the connection point is the separate Dataverse MCP server, reachable at https://<OrgURL>/api/mcp. It exposes four core operations: read_query, create_record, update_record, and describe, the last of which lets a client inspect table and column schema before it attempts a write, which matters a great deal in a Dataverse environment where customizations can mean the “standard” schema an agent expects has drifted from what is actually deployed.

One detail worth building into any design review: the Dataverse MCP server is enabled by default for Microsoft Copilot Studio but disabled by default for every other client. If a team is connecting GitHub Copilot, a custom agent, or any third-party MCP-compliant tool, an admin has to go into the Power Platform admin center, open the target environment’s Settings, navigate to Product > Features, and turn on “Allow MCP clients to interact with Dataverse MCP server,” then explicitly allow-list each client under Advanced Settings. Nothing connects by accident, which is a reasonable default for a capability that can write to production data, but it also means a “why isn’t this working” support call is often really a “did anyone flip this switch” question.

Abstract illustration of two connected server nodes representing the Sales MCP server and Dataverse MCP server architecture

Configuring both servers side by side

For a VS Code or other mcp.json-driven client, the practical setup is two separate server entries pointed at two different endpoints rather than a single unified connection string. The Sales server entry targets the Agent 365 service path scoped to the environment and the Sales MCP server registration, something like https://agent365.svc.cloud.microsoft/mcp/environments/<EnvironmentID>/servers/msdyn_SalesMCPServer, while the Dataverse entry targets the organization’s own API surface directly. Both are declared as HTTP-type MCP servers. Getting an agent to feel like it has coherent access to “Dynamics 365 Sales” as a single system is really a matter of configuring both endpoints correctly and letting the client route each request to the appropriate one, which most MCP-aware clients handle transparently once both connections are live.

It’s worth noting explicitly for architects scoping this work that Claude Desktop is not on Microsoft’s list of supported clients for the Sales MCP server as of this writing; Copilot Studio, GitHub Copilot in VS Code, and other MCP-compliant clients are. That’s a constraint worth confirming before a client commitment gets made in a statement of work.

Security enforcement isn’t a separate layer, it’s the same one

The question every security-conscious stakeholder asks first is whether an AI agent connected through MCP can see or touch more than the person who authorized it could. Microsoft’s own documentation is direct on this point: the Dataverse MCP server respects existing Dataverse security roles and row-level security, meaning a connected agent can only access the tables and records that the authenticated user’s security role already permits. There is no parallel permission model to reason about, no separate access control list to maintain for agent traffic. The security model an organization has already built for its human users through business unit hierarchies, field-level security, and role-based table access extends automatically to MCP-connected agents acting on that user’s behalf. That’s a meaningfully simpler governance story than a lot of teams expect walking into this, and it’s worth stating plainly to a CISO who assumes agent access requires a whole new access-control project.

What isn’t yet documented in detail is rate limiting or granular audit logging specific to MCP calls, and that’s a fair gap to flag rather than paper over. Teams putting this into production should validate logging behavior in their own tenant and treat detailed throttling behavior as something to test empirically rather than something to design around from a published number that doesn’t exist yet.

The licensing detail that changes the cost conversation

Since December 15, 2025, Dataverse MCP tool calls made by AI agents built outside Microsoft Copilot Studio are billed against Copilot credits, unless the organization already holds qualifying Dynamics 365 Premium licensing or a Microsoft 365 Copilot User Subscription License, in which case that usage is included. Agents built inside Copilot Studio are exempt from this particular charge model. The Sales MCP server has its own credit consumption structure layered on top, with different tool categories, such as basic text and generative AI tools versus generative answer tools, billed at different Copilot Studio credit rates. For an architecture that mixes a Copilot Studio-native agent with a custom VS Code-based developer tool hitting the same environment, that means two different cost models are running in parallel, and a licensing conversation that used to be a single line item now needs to account for which client is making which call.

What to check before this goes into a proposal

Confirm which specific tools a client actually needs before assuming both servers are required. A workflow that only needs lead qualification and outreach drafting may never need Dataverse MCP write access at all, which simplifies both the security review and the licensing conversation considerably. Where write access genuinely is required, treat the admin center toggle and client allow-listing as a discrete deployment step with its own change ticket, not an assumed side effect of installing an MCP client. And build the Copilot credit cost of both servers into a pilot’s budget from day one, since credit consumption for generative tools scales with usage in a way that a fixed per-seat license does not.

Teams at Routeget Technologies have walked several clients through exactly this two-server design decision over the past few months, mostly because the documentation, while accurate, spreads the full picture across three or four separate Learn pages that don’t obviously reference each other. Getting the architecture right the first time saves a rework cycle that otherwise shows up a few weeks into a pilot, right around the point someone asks the agent to actually change a record instead of just describing one.

#DynamicsSalesMCP #DataverseMCP #AIinCRM #CopilotStudio #EnterpriseAI #D365SalesArchitecture