Add AI to Dynamics 365 without adding anything you can’t remove.
No fields on your tables. No change to ERP behaviour. It reads through Microsoft’s own supported integration points and proposes; a person approves anything that moves money or stock.
Your implementation partner keeps running your ERP. We have never competed for that work.
What removing it involves
A core customisation
A project. Schema changes remain.
A packaged extension
An uninstall, then cleanup. Orphan fields remain.
A decision layer
Revoke an app registration. Nothing remains in the ERP.
Zero fields added to your tables
Reads through documented entities only.
Runs in your own tenant
Dataverse, Power Platform and Azure.
Your partner’s model is untouched
The seam is documented on purpose.
The loudest worry in this market is not about AI
Read enough Dynamics forums and one theme drowns out the rest, and it is not model quality or cost. It is what is already installed, what it does, and whether anyone could take it out again.
We can't remove it because nobody knows what it does
Extensions installed during an implementation, adding fields to tables nobody asked about, in a vertical the business is not in. The team is not angry about the software. They are stuck with it, and the reasoning behind it left with the people who built it.
Customisation stopped helping and became debt
Every change made the system fit better and made the next upgrade harder. There is no line in the sand, and by the time anyone looks for one it is behind them.
Upgrades break things we did not know were connected
A platform update lands and something unrelated stops working. The blast radius of a customisation is only discoverable after it goes off.
Switching providers means an argument about our own data
Partner-of-record transfers, environments somebody else administers, and the discovery that leaving is a project rather than a decision.
None of that is an argument against extensions, and it is not a criticism of anyone's partner. It is the reason the first question about a new layer should be about removing it, not adding it.
Three ways to extend an ERP, and what each leaves behind
The differences only matter on the day you want something gone.
| A core customisation | A packaged extension | A decision layer | |
|---|---|---|---|
| Adds fields to your tables | Yes | Usually | No |
| Changes ERP behaviour | Yes | Sometimes | No — it reads and proposes |
| Survives a platform update | Needs retesting | Vendor's responsibility | Unaffected — outside the ERP |
| Your partner's support model | May be affected | Depends on the app | Unaffected |
| Removing it means | A project | An uninstall, and cleanup | Revoking an app registration |
| What remains afterwards | Schema changes, sometimes data | Orphan fields, sometimes data | Nothing in the ERP |
| Who can explain what it does | Whoever built it | The vendor's docs | The integration points, listed |
What exists in your estate
An Entra app registration with a scoped service role, and apps running in your own tenant on Dataverse, Power Platform and Azure. Reads go through OData data entities, custom services and Business Events — documented, versioned, and the part Microsoft commits to keeping stable.
What does not
No new fields on your tables. No change to ERP behaviour. No direct database access and no screen scraping — both are dependencies on something nobody promised to keep stable.
What happens when you switch it off?
You revoke the app registration. That is the whole procedure.
The ERP is exactly as it was — same schema, same behaviour, same reports — because nothing was changed inside it. There are no orphan fields to find, no data to disentangle, and nothing that needs the original engineer to explain. What you lose is the analysis. You do not lose a weekend.
We would rather you could leave easily than have you unable to. A layer that is hard to remove is not stickier — it is just harder to say yes to in the first place.
Ask us this in writing
- The list of tables and fields we add. It is empty.
- The integration points we use, named individually.
- The removal procedure, and who runs it.
- What remains in the ERP afterwards.
Ask any vendor the same four, ourselves included. The answers should arrive as a list, not as reassurance.
How do you evaluate a Dynamics add-on for lock-in?
Six questions worth putting to anyone proposing to extend your ERP, us included. They are useful whichever way you decide.
What does it add to the database?
Ask for the list of tables and fields, before signing. If the answer is a conversation rather than a list, that is the answer. A decision layer that reads through documented entities adds nothing, and can say so in one line.
What is the removal procedure?
Not whether it can be removed — the procedure. Who runs it, how long it takes, and what is left behind. Reversibility that has never been written down is a hope, not a property.
Which integration points does it use?
OData data entities, custom services and Business Events are documented, versioned and supported. Anything reaching past them — direct database access, screen scraping — is a dependency on something Microsoft never promised to keep stable.
What happens at the next platform update?
Ask what broke at the last one. A specific answer — the entity that changed shape, the integration that had to be re-pointed — is worth more than a reassurance, and it is a fair question to put to us too.
Does it change what your partner supports?
Get this in writing from both sides. The failure mode is not a refusal — it is two vendors each reasonably believing the other owns a problem.
Who administers the environment it runs in?
If the answer is the vendor, leaving is a negotiation. If it is your own tenant, leaving is an administrative action you can take on a Tuesday.
Where your partner ends and we begin
Your implementation partner owns the ERP: the configuration, the data model, the upgrades, the support model, the relationship. None of that moves. We have never competed for that work and the arrangement stops making sense if we do.
We own the decisions the ERP records but does not derive — the stock level, the price, the pick path, the clause worth arguing about. Those are computed outside the ERP and presented back through documented integration points.
The seam is documented on purpose. The failure mode with two vendors is rarely a refusal to help — it is both of them reasonably believing the other owns a problem.
The writing behind this
- ERP agent permissions are invisible in Entra
- Can an ERP agent escalate its own permissions?
- Which environments run the ERP MCP server
- How should an AI agent read Dynamics data?
- What Copilot cannot do in Dynamics 365
- Why ERP agents report false success
The category, and how an agent reaches ERP data: agentic ERP.
The questions an IT director asks
Do you replace our Dynamics implementation partner?
No, and the arrangement only works if we do not. The partner who implemented the ERP keeps running it — the configuration, the upgrades, the support model, the relationship. We add a decision layer beside it through documented integration points. The two pieces of work stay separable on purpose, so neither of us can hold the other's work hostage.
What exactly gets installed in our environment?
No fields are added to your tables and no ERP behaviour is changed. What exists is an Entra app registration with a scoped service role, and apps that run in your own tenant on Dataverse, Power Platform and Azure. The integration points are OData data entities, custom services and Business Events — all documented, versioned and supported by Microsoft.
What happens if we switch it off?
You revoke the app registration. The ERP is exactly as it was — same schema, same behaviour, same reports — because nothing was changed inside it. What you lose is the analysis, not your data and not a weekend of un-picking. We would rather you could leave easily than have you unable to.
Does this break when Microsoft ships a platform update?
The integration surface is the part Microsoft commits to keeping stable, which is exactly why we use it and nothing else. A layer that reads through supported entities is not in the blast radius of an update the way a core modification is. That is a design choice, not a guarantee about someone else's release.
Is this an app we buy, or a build?
Both exist, and the words are exact. Contract Review Copilot is shipped, running for a customer today as Paralegent AI. The Pricing, Pick-Path and Demand & Inventory Optimizers are built and demonstrated on request against your own data. Several domains are built to order: we have the engineering and build it for you, and there is no packaged app yet. The MCP server and Copilot extension are in development. In every one of those cases the work sits beside the ERP, so what your implementation partner supports does not change.
How much of our process do we have to change?
None of it, to start. The layer computes decisions your team is already making and presents them with the reasoning. Anything that moves money or stock is proposed and prepared, and a person approves it. If the recommendation is that better master data would fix the problem instead, that is a shorter and cheaper engagement and we would rather say so.
Start with the removal question
Bring the four questions above to a working session and we will answer them about our own work first. A scoped four-to-six week pilot on one decision, with one success metric agreed before we begin.