TL;DR
Six checks in the order that blocks a project. Version and tier are binary. The two that stop most pilots are who may connect and who owns the identity.
Six checks, in the order that actually blocks a project. The version and environment tier come first because they are binary — you either pass or you do not. The two that stop most pilots sit further down: who is allowed to connect, and whether anybody owns the agent identity.
Why does the order matter?
Because the binary checks are cheap and the organisational ones are slow.
A version check takes a minute. Working out who approves a new agent identity, and who reviews its roles, can take weeks — and it is not technical work, so it rarely gets started until someone notices it is on the critical path.
Run them in this order and you discover the expensive problems first, while there is still time to move them.
Checks 1 and 2 — the version and the environment
These are published requirements and they are absolute.
The ERP MCP server has a version floor and an environment-type constraint. We have covered both in detail already — the floor, the acceptable quality updates, the tier requirement, and the environment types that are excluded — in which environments can run the ERP MCP server.
What to do here: confirm the version of the environment you intend to pilot in, not the version of production. Pilots routinely get scoped against a sandbox that turns out to be on an older update, and the check costs nothing until it is late.
And one thing people forget: the MCP server is enabled per environment. Confirming production is capable tells you nothing about the sandbox you will actually build in.
Check 3 — who is allowed to connect?
This is an allow-list, and it defaults to a short one.
"Administrators can also control which agent clients are allowed to connect to the MCP server. When you enable the Dynamics 365 ERP MCP server in your environment, choose which agent platforms can access the server."
And the default set is explicit: "By default, only the following platforms can access the MCP server" — the list Microsoft publishes, with a client ID against each, starting with Microsoft Copilot Studio.
### Why this stops pilots The decision is an administrator's, and it is a governance decision rather than a technical one. A delivery team can have everything else ready and still be waiting on a conversation about which agent platforms are permitted to reach the ERP. Start that conversation first. It has an owner, and the owner is probably not on the project.
What to do here: establish which client you intend to use, check whether it is in the default set, and if it is not, find out what registering it involves in your organisation. Allow weeks, not days.
Check 4 — whose identity does the work?
Decide this before you design anything, because it determines what is possible.
Microsoft names two patterns: a delegated agent that runs "on behalf of the user who is chatting with the agent", and an autonomous agent where "The autonomous agent has its own identity, and that identity is the authenticated user making the request."
And the hard constraint behind both: "The MCP server doesn't provide an anonymous or shared-service path for accessing finance and operations data."
What to do here, in order:
- Name the humans the process depends on. Not roles — actual people or job functions.
- Check which of them have an ERP identity. This is where most procure-to-pay processes fail, because the person who knows what arrived often does not.
- If they do not, you need the autonomous pattern and a mediated confirmation step, which is a design problem rather than a configuration one.
- Assign an owner to the agent identity. Somebody reviews its roles, and removes it when the process ends.
Checks 5 and 6 — duties, and where the data goes
Check 5 — validate segregation of duties after you assign the roles, not before.
"Compliance with the rules for segregation of duties isn't verified when you create a rule… You must validate compliance after you create or modify a rule."
The same applies to assignment. A new agent identity with a plausible set of roles can be in conflict with an existing rule and nothing will announce it. Run the validation as a deliberate step, and run it again whenever either side changes — the pair to watch is named in Microsoft's own example.
Check 6 — decide where the agent's data is retained.
"Any data movement or retention outside the customer's finance and operations environment would be dependent on the data storage and retention policies of the agent client… Ensure you audit the agent client's permissions to move data to other systems and the data retention policies."
The server itself holds nothing: "The MCP server doesn't store customer data."
What to do here: decide what the agent's working record is, where it lives, and how long you keep it. If any of it is control evidence, that decision belongs to whoever owns your retention policy, not to the project.
What is deliberately not on this list
Three things, and leaving them off is the point.
Model choice. It changes, it is documented on a page that changes with it, and it is reversible. Checking it early buys nothing.
Cost modelling. It matters, and it is a function of your volumes rather than a readiness gate. It cannot be answered before the process is scoped, so putting it first produces a number nobody can rely on.
Whether your data is clean enough. The honest version is that you find out by running a read-only pass against your own data. A readiness checklist that includes "have good data" is not a checklist — it is a way of deferring the only test that answers the question.
### Where we are, honestly We have built two agents on this ground and they run on test data. The Teams confirmation card and Outlook notice are designed and in build, not shipped. No published results exist for this problem — ours or anyone's. A scoped, read-only look at your own open lines is the honest first step, and it doubles as check six.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.
More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.
Six checks, and two of them need somebody outside your project. If you want to know which two will bite you, bring your environment and your process to a 15-minute call.
Sources
- Use MCP for finance and operations apps · fetched and read in full 2026-10-21
- Security for Dynamics 365 ERP MCP · fetched and read in full 2026-10-21
- Set up segregation of duties · fetched and read in full 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The binary checks are cheap and the organisational ones are slow | T2 — ours, a project-management argument. No duration is quantified as measured — "weeks, not days" is advice, not a finding | — | PASS |
| 2 | 2 | The version floor and environment-tier requirements | Deliberately NOT restated here. The article links to our existing article rather than re-publishing facts covered in six other files. This is the depth gate working | — | PASS — see note |
| 3 | 2 | The MCP server is enabled per environment | T1 — the page describes enabling it "in your environment" and choosing platforms at that point | mcp-security | PASS |
| 4 | 3 | "Administrators can also control which agent clients are allowed to connect to the MCP server. When you enable the Dynamics 365 ERP MCP server in your environment, choose which agent platforms can access the server" | T1 — verbatim | Same page | PASS |
| 5 | 3 | "By default, only the following platforms can access the MCP server", and that Microsoft publishes a client ID against each | T1 — verbatim. The specific IDs are not reproduced — they are environment configuration, not a reader-facing fact, and they change | Same page | PASS |
| 6 | 4 | Both identity patterns quoted | T1 — verbatim ×2 | Same page | PASS |
| 7 | 4 | "The MCP server doesn't provide an anonymous or shared-service path for accessing finance and operations data" | T1 — verbatim | Same page | PASS |
| 8 | 4 | The person who knows what arrived often has no ERP identity | T2 — ours, offered as the common case in procure-to-pay. No proportion is claimed | — | PASS |
| 9 | 5 | "Compliance with the rules for segregation of duties isn't verified when you create a rule… You must validate compliance after you create or modify a rule" | T1 — verbatim | set-up-segregation-duties | PASS |
| 10 | 5 | The same exposure applies to a new role assignment, not only a new rule | T1 — the page states "Existing user role assignments can also conflict with the new rule"; the inversion is ours and is a reading | Same page | PASS |
| 11 | 5 | The retention quotation and "Ensure you audit the agent client's permissions to move data to other systems" | T1 — verbatim ×2 | mcp-security | PASS |
| 12 | 5 | "The MCP server doesn't store customer data" | T1 — verbatim | Same page | PASS |
| 13 | 6 | The three deliberate omissions — model choice, cost modelling, data quality | T2 — ours, scoping judgement | — | PASS |
| 14 | 6 | A checklist containing "have good data" defers the only test that answers the question | T2 — ours, an opinion, stated as one | — | PASS |
| 15 | 6 | Our agents run on test data; Teams and Outlook are designed and in build, not shipped; no published results exist | T2 — REQUIRED disclosure per the source document's guardrail table | — | PASS |
Tier summary: 9 × T1 (all verbatim), 6 × T2 — 0 × T4.
### ⚠️ Claim 2 — this article deliberately does NOT restate the version facts The version floor, the acceptable quality updates, the environment tier and the excluded environment types are already published across six of our own articles. Restating them here would make this the seventh. So §2 links out instead of repeating. That is the depth gate working as intended: the demand brief for this cluster capped the readiness group at one article for exactly this reason, and the readiness article's job is the order of the checks, which nobody else has written, not the facts, which we already have.
### 🔴 Guardrails applied | Rule | Compliance | |---|---| | Never "least-privilege" | Not used. §4 says "assign an owner" and "reviews its roles" | | Never "SOX-compliant" or "100% audit-ready" | Not used. §5 describes the validation step and makes no compliance promise | | Never "Teams and Outlook are live" | §6 states designed and in build, not shipped | | Never a customer name, saving or percentage | None appears | | Do not quote Microsoft's pricing | §6 declines to model cost, and gives the reason rather than a figure |
🔴 No pricing. §6 names cost modelling as deliberately out of scope and states no rate, credit price or currency. This is the cluster's no-pricing ruling applied to the one article where a reader would most expect a number.
No unbounded absence claimed. Every negative is Microsoft's own — doesn't provide an anonymous path, isn't verified when you create a rule, doesn't store customer data.
No figures of ours. No volume, no durations presented as measured, no customer, no result. "Weeks, not days" is advice about approval cycles and is phrased as advice.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
