---
title: "Add AI to Dynamics 365 Without Lock-In"
canonical_url: "https://cognilium.ai/dynamics-365/ai-without-lock-in"
slug: "dynamics-365/ai-without-lock-in"
section: "dynamics-365"
page_type: "pillar"
date_modified: "2026-09-29"
description: "What an AI layer adds to your Dynamics 365 estate, what it does not, and what happens when you switch it off. No schema changes, no partner disruption."
publisher: "Cognilium AI"
author: "Mudassir Marwat"
person_same_as:
  - "https://www.linkedin.com/in/mudassir-marwat/"
  - "https://orcid.org/0009-0008-1927-2598"
  - "https://github.com/mudassirmarwat"
  - "https://medium.com/@mudassir-marwat"
  - "https://www.youtube.com/@mudassir-marwat"
  - "https://dev.to/mudassirmarwat"
  - "https://hashnode.com/@mudassirmarwat"
  - "https://huggingface.co/mudassirmarwat"
  - "https://bsky.app/profile/mudassir-marwat.bsky.social"
  - "https://substack.com/@mudassirmarwat"
  - "https://topmate.io/mudassirmarwat"
  - "https://fueler.io/mudassirmarwat"
  - "https://www.instagram.com/mudassirmarwat/"
  - "https://www.facebook.com/mudassir.marwat"
  - "https://www.reddit.com/user/mudassirmarwat/"
  - "https://www.f6s.com/member/mudassir-marwat"
  - "https://cognilium.ai/founder"
answers:
  - "Does adding AI to Dynamics 365 create vendor lock-in?"
  - "What happens to an AI layer at the next platform update?"
  - "Does an AI decision layer change what my implementation partner supports?"
  - "What remains in the ERP if we remove the AI layer?"
  - "Which integration points does a decision layer use?"
entities:
  - name: "Microsoft Dynamics 365"
    id: "https://cognilium.ai/#entity-dynamics365"
    url: "https://www.microsoft.com/en-us/dynamics-365"
    same_as:
      - "https://www.wikidata.org/wiki/Q27556059"
      - "https://en.wikipedia.org/wiki/Microsoft_Dynamics_365"
  - name: "Microsoft Dynamics 365 Business Central"
    id: "https://cognilium.ai/#entity-businessCentral"
    url: "https://www.microsoft.com/en-us/dynamics-365/products/business-central"
    same_as:
      - "https://www.wikidata.org/wiki/Q58883729"
  - name: "Microsoft"
    id: "https://cognilium.ai/#entity-microsoft"
    url: "https://www.microsoft.com"
    same_as:
      - "https://www.wikidata.org/wiki/Q2283"
      - "https://en.wikipedia.org/wiki/Microsoft"
  - name: "Microsoft Azure"
    id: "https://cognilium.ai/#entity-azure"
    url: "https://azure.microsoft.com"
    same_as:
      - "https://www.wikidata.org/wiki/Q725967"
      - "https://en.wikipedia.org/wiki/Microsoft_Azure"
  - name: "Microsoft Power Platform"
    id: "https://cognilium.ai/#entity-powerPlatform"
    url: "https://www.microsoft.com/en-us/power-platform"
    same_as:
      - "https://www.wikidata.org/wiki/Q106253893"
      - "https://en.wikipedia.org/wiki/Microsoft_Power_Platform"
related:
  - "https://cognilium.ai/dynamics-365"
  - "https://cognilium.ai/dynamics-365/built-to-order"
  - "https://cognilium.ai/agentic-erp"
---

# Add AI to Dynamics 365 Without Lock-In

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 teams are actually afraid of

### 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.


## Customisation, extension and decision layer compared

|  | 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 |


## The four questions to ask any vendor

### 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.


## Questions

### 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.


---

Canonical HTML: https://cognilium.ai/dynamics-365/ai-without-lock-in