How Dynamics 365 apps connect

The most important thing to understand about Dynamics 365 is that it isn't really one application — it's a portfolio of apps wired together by a shared platform. Some of those wires are welded on; others are cables you have to run yourself. Knowing which is which is the difference between an architecture that scales and one that fights you forever.

This guide walks the layers from tightest to loosest.

Identity: the tightest connection

Every Dynamics 365 app authenticates against Microsoft Entra ID (formerly Azure AD). One login covers Sales, Business Central, Finance, the Power Platform, and Microsoft 365 — including from Outlook, Teams, and SharePoint. Conditional access, MFA, and group-based licensing apply uniformly.

This one you never build. It also quietly does more than sign-in: security roles map to Entra groups, service-to-service integrations authenticate as Entra app registrations, and guest access for external users rides the same rails. Whatever else your architecture looks like, identity is solved.

Data: one native layer, two worlds

The CRM-side apps run natively on Dataverse. Sales, Customer Service, Field Service, Customer Insights – Journeys, and the front half of Project Operations are all model-driven apps over the same database. Install them in one environment and they share the same Account, Contact, and User tables as rows, not copies. A case in Customer Service links to the same account record the sales team works. Cross-app security, reporting, and automation work without any ETL, because there is no ETL — it is one database wearing several apps.

The ERP-side apps have their own databases. Finance and Supply Chain Management run on their own transactional store; Business Central has one database per company per environment. Neither runs on Dataverse. So a Customer in Business Central is not automatically the same record as an Account in Sales — if you run both, something must keep them aligned.

Microsoft ships that something, but you configure, own, and monitor it:

• Dual-write synchronises Finance/SCM tables with Dataverse in near-real time, both directions, with out-of-the-box maps for customers, vendors, products, and more. It is genuinely good — and it is still an integration, with initial-sync projects, conflict rules, and error queues to manage.
• Virtual tables surface Business Central data inside Dataverse without copying it — reads and writes pass through to BC live. Great for lookups and light scenarios; not a replication layer.
• Beyond the boxed options sit the general integration patterns — the same tools you'd use for any third-party system.

The honest rule: inside Dataverse, data connections are free; across the ERP line, every connection is a small project. Budget accordingly.

Analytics: the lake everyone drains into

Reporting inside one app is built in. Reporting across apps converges on a shared analytical layer: Azure Synapse Link streams Dataverse tables to a lake, F&O exposes its data the same way, Business Central has its own APIs and lake export paths, and Microsoft Fabric is where Microsoft is pointing all of it — shortcut the sources into OneLake, model once, report with Power BI on top. Cross-app analytics is a solved pattern, but it lives in the analytics layer, not inside the apps.

Workflow and AI: the loose, flexible layer

The Power Platform is the connective tissue that doesn't care which side of the ERP/CRM line an app sits on. Power Automate flows trigger across any combination — a won opportunity in Sales creates a project in Business Central; an F&O purchase approval pings Teams. Power Apps builds custom front ends over any of the data. Copilot Studio agents read and write across the estate. These connections are quick to build, which is their strength and their governance problem — hundreds of ungoverned flows are an integration architecture, just an undocumented one.

Microsoft 365: where users actually live

Files attach to SharePoint and OneDrive through built-in document management. Outlook synchronises email and appointments into CRM. Teams embeds records and channels both ways. These integrations are configuration, not code — and they matter more than they sound, because adoption lives or dies on whether Dynamics meets people inside the tools they already use.

What this means for your architecture

Four planning rules fall out of the layer map:

1. Co-locate the CRM apps. Apps that share a Dataverse environment share everything. Splitting Sales and Customer Service into separate environments forfeits the platform's best feature — do it only for hard data-isolation reasons.
2. Treat the ERP boundary as a real integration boundary. Mixing a CRM app with a separate ERP is normal and supported, but name an owner for the sync, monitor it, and decide up front which system masters customers, products, and prices. Most "Dynamics is broken" complaints in mixed estates are actually "nobody owns dual-write."
3. Put cross-app reporting in the analytics layer — Synapse Link or Fabric — rather than hammering operational APIs with reporting queries.
4. Govern the loose layer early. Power Automate will connect anything to anything; environment strategy and DLP policies decide whether that's an asset or an audit finding.

The integration cost between the halves is the price of the platform's modularity. It's a fair price — the boxed connectors are better than what you'd build — but plan for it from day one, not after go-live.

Next step in the path: how to choose the right Dynamics 365 product.