TL;DR
Most teams that can't activate Microsoft's Dynamics 365 agents aren't blocked by the AI — they're blocked by data quality, role design, customizations and governance. Here's the honest readiness checklist.
Here's the pattern almost every team discovers the moment they try to activate agents on Dynamics 365: the AI isn't the hard part.
The agents are good. The platform is ready. What's not ready is the estate they're being pointed at — the data quality, the role design, the customizations, the governance. That's why "readiness" has become the first word in every serious agentic-ERP conversation, and why it deserves an honest checklist rather than a sales sprint.
So here it is — the five things that actually determine whether you can turn agents on safely and get value, in Dynamics terms.
1. Is your data clean enough for an agent to trust?
An agent acts on what the ERP tells it. If your vendor master has duplicates, your item data has gaps, or your custom fields are inconsistently populated, the agent inherits every one of those problems — and acts on them at speed. A human quietly works around bad data; an agent doesn't know it's bad.
Ready when: the data the agent will read for its target process is complete, de-duplicated and consistent. Not perfect everywhere — clean where this agent operates.
2. Is your role design safe to hand to an agent?
An agent acting for a user currently inherits that user's full permissions and acts on natural-language instructions. In most long-lived Dynamics estates, roles have drifted — people accumulated access they no longer need, segregation of duties blurred. That drift is tolerable on a careful human; it's a real exposure on an agent.
Ready when: roles are audited, segregation of duties holds, and no agent can both create and approve the same transaction. (This is the governance gap — the single most common reason to pause before activating.)
3. Can the agent reach your customizations?
First-party agents reason over standard Finance & Operations. If your estate carries real X++ customizations and ISV logic — and most do — the agent is blind to exactly the parts that make your process yours.
Ready when: the specific operations an agent needs on your customizations are exposed as governed MCP Action tools, scoped inside your security roles — so the agent can act on your F&O, not a standard one.
4. Are your procedures written down anywhere but people's heads?
An agent follows generic behaviour unless you give it yours. Your approval thresholds, your exception handling, the rules a seasoned controller applies by instinct — if those live only in people's heads, the agent can't apply them.
Ready when: the procedure for the target process is captured and codified as governed business skills — including the exceptions, which is where the value is.
5. Is there a human-approval gate on anything irreversible?
The safe pattern — the one Microsoft's own flagship demo uses — is that the agent prepares the work and a person approves before anything irreversible posts: the PO, the payment, the entry.
Ready when: approval-before-posting is architectural, not optional, and every agent action is traceable to the instruction, the approval and the record.
How to use this checklist
Score honestly, per process, not for the whole estate at once. You don't need every process ready — you need one ready, where the value is real: a named process (reconciliation, PO confirmation, RFQ, quoting) with clean-enough data, safe roles, reachable customizations, codified procedure, and an approval gate.
That's the difference between a readiness exercise that produces a report and one that produces a process you can actually turn an agent loose on — safely — next quarter.
If you want an honest read on whether a specific process is ready — and what the shortest path to "yes" is — tell us the process and what your estate looks like. The first conversation often ends in "fix these two things first," and that's the point.
Share this article
Agentic ERP
Topic Cluster
