AI on Top of Dynamics 365 and SAP: Integration Patterns That Ship

How to add AI and analytics on top of Dynamics 365, SAP, or your ERP without a rip-and-replace. The integration patterns for AI Dynamics 365 integration that actually reach production, the permission and freshness traps, and a checklist before you start.

Your Dynamics 365 or SAP install is where the real data lives: orders, inventory, GL entries, service tickets, master data. That is exactly why the instinct to rip it out and rebuild around an AI product is usually the wrong call. The platform is the system of record. What buyers actually want is a reasoning and retrieval layer sitting on top of it: ask a question in plain language, get an answer grounded in current ERP data, and let a human approve anything that writes back.

Rip-and-replace is a multi-year program with a hard failure mode. Adding AI on top is a scoped project you can ship in weeks, measure, and expand. The patterns below are the ones we see actually reach production.

The patterns that ship

1. 1Read-only grounding over ERP data. Start by giving the AI read access, not write access. Pull the entities that answer real questions (orders, stock, invoices, customer records) into a retrieval layer and ground every response in that data. Read-only removes most of the risk while delivering most of the value, and it is the fastest path to something a business user trusts.
2. 2Event-driven sync. Do not poll the ERP on a timer and hope. Subscribe to platform events. Dynamics 365 exposes the Dataverse change-tracking API and Azure Service Bus events; SAP exposes events through its event mesh and CDS view change data capture. Push changes into your index as they happen so the AI reasons over current state, not last night's export.
3. 3A governed retrieval layer with permissions. This is the pattern most demos skip and most enterprise procurement blocks on. The retrieval layer has to respect the same permissions as the ERP. If a user cannot see a cost field or another region's pipeline in Dynamics, the AI must not surface it either. Permissions belong in the retrieval query, enforced per user, not bolted on after the model responds.
4. 4A human approval boundary for write-back. When the AI does propose a change (update a record, create a purchase requisition, close a ticket) route it through an approval step. The model drafts, a person confirms, and only then does the write hit the ERP. This one boundary is what turns a demo into something a finance or operations team can deploy.

The traps

Permissions and row-level security

The single hardest part is not the model, it is mirroring row-level and field-level security into retrieval. Get the entitlement model wrong and you have built a data-leak engine that is convincing and fast. Design the permission mapping before you index a single row.

Data freshness

An answer that is confidently wrong because it is stale is worse than no answer. Decide the freshness SLA per entity up front. Pricing and inventory may need seconds; a closed fiscal period can tolerate hours. Match the sync mechanism to the requirement.

Change management

Adoption is a people problem. If users cannot see why the AI said what it said, they will not trust it and they will not use it. Show sources, show the underlying records, and give operators a way to correct the system. Trust is earned through transparency, not accuracy claims.

What this looks like in practice

For Hindustan Unilever we built an AI knowledge assistant for a 15,000-person supply chain organisation. It integrated 12 internal systems, including SharePoint and ERP, behind single sign-on with role-based access control, so every user sees only what their role permits. The ERP was never replaced. The AI sat on top of it and the systems around it, and the permission model was the design centre of the project, not an afterthought.

For EY the constraint was auditability. We integrated 8 source systems, including ERPs and legacy workpaper tools, with field-level access control scoped per engagement team, and we wrote every AI decision to an immutable audit log. That is the shape of AI a regulated buyer will actually put into production: governed access, and a record of what the system did and why.

Checklist before you start

• Name the 5 to 10 questions the AI must answer on day one, and the entities behind them.
• Map row-level and field-level security from the ERP into the retrieval layer before indexing anything.
• Choose read-only grounding first; treat write-back as a later phase.
• Set a freshness SLA per entity and pick event-driven sync where seconds matter.
• Define the human approval boundary for every write path.
• Decide what gets logged, for how long, and who can review it.
• Pick one workflow with a measurable baseline so you can prove the change.

How we engage

This is our enterprise platforms practice: AI, analytics, and integration on top of and around Dynamics 365, SAP, and other ERPs. We are not selling you a platform migration and we do not claim to be a certified Microsoft or SAP partner. We build the retrieval layer, the permission mapping, the event sync, and the approval workflow that make AI safe to run over the system you already own. Typically we start read-only, prove one workflow, then expand.

If you own a Dynamics 365, SAP, or ERP platform and want AI on top of it without a rip-and-replace, book a call and we will scope a first workflow. You can also read more about our enterprise platforms practice.