What can't Copilot do in Dynamics 365

What can't Copilot do in Dynamics 365 — and what do you build instead?

Every article about Copilot in Dynamics 365 ends in the same place: use it, carefully. This one starts where those stop. Written for the architect who has to sign the design, not the exec who has to approve the pilot.

9 minute read.

The boundary is not a feature gap

Microsoft's ERP AI stack is more complete than its critics think and less finished than its marketing implies — and neither of those is the interesting part. The interesting part is that the boundary is not a list of missing features. It is a set of engineering decisions Microsoft has deliberately left to you.

There are four of them: how the agent is scoped, which data surface it reads, how it fails, and what it costs. Microsoft documents each surface honestly and then stops at the point where a design decision starts. That gap is not an oversight. A platform vendor cannot make those calls for every customer, so it ships the runtime and leaves the architecture.

The result is that two teams can deploy the same Copilot features and get opposite outcomes. The difference is never the model. It is whether anyone answered the four questions before go-live.

What Copilot actually is inside finance and operations

Microsoft frames it in three shapes, and knowing which shape you are looking at tells you where the extension points are.

**Sidecar — generative help and guidance [GA] — What it is: Chat panel beside the app. Microsoft: "deeply grounded in the official public documentation for Microsoft finance and operations apps" · What it does not do: Grounded in documentation, not in your records.** Answering over your own data is a separate capability someone configures
**Embedded — AI inside a specific page [GA]** — What it is: Purpose-built surfaces such as the confirmed purchase-order changes workspace · What it does not do: Does not generalise. Each one is its own feature with its own boundary
**Outside — agents orchestrating across apps** — What it is: Copilot Studio agents and Microsoft 365 agents reaching the ERP through the Dynamics 365 ERP MCP server [GA] 27 January 2026 · What it does not do: Does not arrive configured. This is where all the design work lives

That first row surprises people. Microsoft describes generative help as grounded in public documentation and searched through "the Bing search index … in the learn.microsoft.com domain" (copilot-generative-help).

Answering questions over your own ERP (enterprise resource planning) records is a separate capability — chat with finance and operations data — and it works by someone choosing specific entities, surfacing them through virtual tables or dual-write, and registering them as a knowledge source (chat-with-fno-data).

Its status is a split verdict, so treat it as one. The release plan shows "Ask about your ERP data in natural language" at general availability 26 January 2026; the article itself is still titled "(preview)" and still opens "[This article is prerelease documentation and is subject to change.]" Take the plan's date, keep the doc's caution.

Which produces the sentence that should be on the first slide of every ERP-AI kickoff:

Coverage is a configuration decision, not a product guarantee.

Nobody is wired to every table by default. If a stakeholder believes the ERP became conversational the day Copilot was switched on, that belief will survive right up until the first question that returns nothing, and then it will take the project's credibility with it.

The runtime surface, and the thing it does not include

The Dynamics 365 ERP MCP server is the strategic piece. MCP (Model Context Protocol — the open standard that lets an agent discover and call functions in another system) exposes the application's own runtime surface: data entities, forms and X++ (the finance and operations programming language) actions, filtered on every call by the caller's security role.

It reached [GA] on 27 January 2026. That date is on the release plan, not the product page: the 2025 release wave 2 finance and operations cross-app plan shows "Connect AI agents to finance and operations data and business logic" at general availability Jan 27, 2026 (release plan).

On its own blog, dated 11 November 2025, Microsoft wrote "All new ERP agents will be built using MCP" (Dynamics 365 blog). That is a vendor statement about the protocol — marketing, not documentation, and not a claim about this server specifically.

It is architecturally unusual, and the consequences are worth sitting with:

Extensions are reachable without connector work — A custom form your ISV deploys is agent-addressable the day it ships
Security roles scope what the agent reaches — Microsoft documents no separate agent-permission layer on top of them, and on the Copilot Studio side "MCP servers … don't add API permissions to the Entra Agent ID". The roles are the API surface
The contract is unstable by design — Form changes change agent behaviour. Agent regression testing is now part of your release cycle

Read the middle row again, because it is the whole security conversation. An agent's blast radius is the set of security roles on the identity it authenticates as — plural, because Microsoft's permission-less System agent role, which exempts the identity from user licensing, sits alongside whichever roles grant it actual access.

Microsoft illustrates the filter with a Purchasing Agent role and states the reason in terms that are not only about safety: "Limiting the menu items, entities, and APIs by using roles is important for limiting the scope of the agent. It also improves agent orchestration by limiting the context the agent needs to orchestrate over to find the right form, data, or actions."

Least privilege makes the agent better, not just safer. Microsoft stops there. Building a purpose-built role per agent instead of reusing a broad one is our design rule.

Two more controls sit outside those roles. The Allowed MCP clients page decides which agent platforms may call the server at all, and Microsoft ships it with a default list you should read before anyone extends it.

The second is the Power Platform data policy. In Copilot Studio, "Access to MCP servers … relies on Power Platform connectors for connectivity … if a data policy regulates Power Platform connectors, it also regulates access to the MCP server and its tools for your agent" (mcp-add-components-to-agent).

The four questions, and where each one is answered

This is the map of the rest of this cluster. Each question below is a real design decision with a documented answer, and each one has cost somebody a project.

Scope — what can this agent reach, and can it reach further tomorrow?

In-app Copilot sidecar or a Copilot Studio MCP agent — which one, for what? (Microsoft's known limitation 10: "Adding the Dynamics 365 ERP MCP server as a tool in the Copilot for finance and operations apps agent, enabling it for use with the sidecar chat panel in the client, isn't yet supported." copilot-mcp)
Can an AI agent in Dynamics 365 give itself more permissions? (Microsoft blocks a specific, nameable list of system-administration forms — the answer is a form-name list, not a promise.)
Do I need a Dynamics 365 licence for an AI agent's identity?
Why can't I see my ERP agent's permissions in Entra? (Microsoft's word is "Today": "custom connectors, MCP servers, and REST API tools added to agents don't add API permissions to the Entra Agent ID." Copilot Studio. Current scope, not a stated design commitment — re-check each wave.)

Freshness — which surface is this answer coming from?

Why is my ERP agent answering with yesterday's numbers?
Should an agent read Dynamics data through the MCP server, virtual tables, dual-write, or the ERP Analytics MCP server [PP]?

That analytics surface is the Dynamics 365 ERP Analytics MCP server, and it is [PP] — Microsoft's page is titled "(preview)" and states "Preview features aren't meant for production use and might have restricted functionality." Pilot an analysis agent on it. Do not put a go-live date on it.

The cadence is on the same page: Business performance analytics pre-transforms "currently run twice daily (12-hour intervals)". Two facts sit on top of that interval and both make it worse. The refresh runs on a fixed clock — "12:00 AM and 12:00 PM (Coordinated Universal Time)" — and "the full pipeline (data sync, transforms, and refresh) can take 4-5 hours or more".

So the rule is: if the answer changes within 12 hours it does not belong on the analytics surface, and 12 hours is the floor on staleness rather than the ceiling. Availability goes to the transactional server; inventory turns can live here.

Failure — how do I know it went wrong?

Are Dynamics 365 ERP form tools just RPA (robotic process automation — software that drives an application's screen the way a person would) with a new name?
Why did my ERP agent report success when the write actually failed?
How do I expose my own X++ business logic as an agent tool?

Cost and lifecycle — what does this meter, and what expires?

What does a Dynamics 365 ERP agent actually cost to run?
What happens to my ERP agent on 1 October 2026? (Microsoft: the static server "will be retired on October 1, 2026" — [DEPR], copilot-mcp. Our read: moving to the dynamic server is a rewrite, not a port.)
What can the Procurement Agent [PRP] not do yet? (Microsoft publishes the list under "The agent doesn't currently support the following scenarios" — splitting a line into multiple deliveries, changing the delivery site for a line, changing the vendor on a line or an order supplier communications. For an automotive supplier, those are routine daily traffic.)

Twelve questions. Not one of them is answered by "use Copilot, carefully."

What we build in that gap

We are an AI optimization ISV, not an implementation partner — we do not touch the ERP core and we do not step on the partner who put it in. What we build is the layer that surrounds it, and on this stack that layer is four disciplines:

Role-first agent design. The security role is designed before the prompt, because the role is the API surface. A purpose-built role per agent, never a broad one.

A read/write split by data freshness. Analysis agents read the analytics surface and say so. Action agents read the transactional surface. They are different agents with different groundings, and conflating them is how an agent answers "is it available?" with half-day-old confidence.

Write-back as a proposal. Every optimized decision an agent produces — the buffer, the price, the ranked work order — lands in an approval queue before it reaches the system of record. A wrong buffer is trapped cash; a wrong price is a customer conversation.

Agent lifecycle in the release pipeline. Because the MCP contract moves with your forms, agent regression tests belong in the same pipeline as the deployable package. This is the discipline the market does not yet have, and it is the one that decides whether an agent survives its second platform update.

Where it goes wrong

Four patterns. Two rest on limits Microsoft documents; two are our engineering judgement, marked as such:

One large agent on a broad security role — Bigger context, worse tool selection, more calls, higher bill, weaker security posture — all at once
Grounding an availability agent on the analytics surface — Half-day staleness makes it wrong for exactly the questions people ask it
Screen-driving the ERP with external robotic automation — Microsoft's form tools "work through server APIs that provide the agent with the application view model as context, enabling more optimized agent interactions" — no client session opens. Our judgement: the screen-driving version is slower and more brittle
Building anything new on the retiring static server — It is [DEPR] with a dated retirement, and the successor is not a like-for-like swap

The pattern underneath all four: treating an ERP agent as a product you switch on rather than a system you design.

The counter-argument, stated fairly

"Wait. Microsoft is shipping this quickly — server-side tool-path optimisation is already on the plan, and half of what you call design work will be absorbed into the platform. Why build discipline around a moving target?"

That objection is right about the direction and wrong about the timing. The feature is real and it is named: "Boost agent performance with optimal tool execution paths in Dynamics 365 ERP MCP", [PLAN] — public preview Jun 2026, general availability Oct 2026, neither marked released on the 2026 release wave 1 plan as of its 28 July 2026 revision (release plan).

Microsoft describes it as "enabling the server to use optimal tool execution sequences to perform operations". When it ships it will make hand-tuned prompt engineering worth less. Design for that: do not build a business on prompt cleverness the platform will absorb.

What the platform will not absorb is the part that is specific to you. Your security role design, your freshness split, your approval gates, your regression suite. Microsoft cannot ship those, because they are decisions about your organisation, not about the product. Every wave makes the runtime better and leaves that list exactly where it is.

What to do this week

Open the Allowed MCP clients page in your finance and operations environment. That grid decides which agent platforms may call the server at all, and it ships with a default list. Know what is on it before someone else adds a row.
List every agent you have running or piloting, and write down the security role each identity holds. If any of them holds a broad role, you have found your first design task.
Take your three most-asked ERP questions and mark each one changes within 12 hours or does not. That split is your agent architecture, and it takes about ten minutes. Treat 12 hours as the floor — the refresh pipeline adds hours of its own on top.

Where we would draw the line

We would not put an agent's write path into production without an approval step, whatever the demo looked like. We would not build a customer's foundation on a preview feature — and that includes the ERP Analytics MCP server [PP]. Label it, pilot it, keep it off the critical path.

We would not build a conversational front door as the product; the domain reasoning underneath the chat box is the product. And we would not accept a design where the answer to "what can this agent reach?" is anything other than the name of a role.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are inside this decision now, we will walk your agent architecture with you on a call — the role design, the freshness split and the write path. No deck. https://cognilium.ai

— Cognilium. We optimize the decisions your ERP can only manage.

What can't Copilot do in Dynamics 365 — and what do you build instead?