Microsoft Dynamics 365 · Integration
Microsoft Dynamics 365 only delivers its full value when it is cleanly connected to ERP, marketing, telephony, DMS, accounting, and e-commerce. We cover the six common integration patterns, ten typical scenarios in the mid-market, and three architecture approaches — vendor-neutral and with an honest view of the effort involved. Microsoft Partner since 2007, with over 20 years of integration practice around Dynamics 365 and Dataverse.
Terminology
The term "integration" is used in the Microsoft world for three very different tasks. Anyone meaning different things with the same words ends up building a solution nobody asked for.
System integration. Two or more systems exchange functions — for example, Dynamics 365 Sales calls a function in Business Central to create an order. It's about process steps that run in different tools but should be perceived as one connected operation.
Data integration. Records are synchronized between systems — master data such as customers, items, and accounts, or transactional data such as invoices and documents. Here, consistency, conflict resolution, and the understanding of which system owns the truth on which field are what matter.
Process integration. A business process runs across systems, often asynchronously and with human decision points. Example: an offer approval starts in Dynamics 365, is decided in Microsoft Teams, documented in the contract DMS, and triggers order creation in the ERP.
In practice the three tasks overlap. Anyone who thinks of Dynamics 365 integration as REST calls only overlooks the data quality and process steering parts — and that's exactly where most integration pain in daily operations comes from.
Six integration patterns
There is no "the right" Dynamics 365 integration — there are six established patterns, each made for different scenarios. The pattern choice is the most important architecture decision and determines maintainability, performance, and total cost of ownership.
Pattern 01
The standard for modern SaaS systems with a documented REST interface. Dynamics 365 provides a complete OData endpoint via the Dataverse Web API; many third-party systems offer REST or GraphQL. Advantages: low latency, clear contracts, easy versioning. Limits: no built-in retry and mapping layer — you have to build those cleanly yourself.
When does this fit? Modern SaaS-to-SaaS exchange without heavy mapping load, manageable load, clear synchronous logic.
Pattern 02
A dedicated integration layer between systems. Azure Logic Apps and Power Automate provide hundreds of pre-built connectors, mapping tools, and retry mechanisms. For demanding setups add Azure Service Bus and Azure API Management. Advantages: readable workflows, built-in error handling, good maintainability. Limits: license cost for premium connectors, capacity planning.
When does this fit? Complex mapping logic, many endpoints, citizen-developer involvement, or regular business-side changes to the workflow.
Pattern 03
Periodic bulk exchange, typically nightly or several times a day. Azure Data Factory orchestrates the pipelines; the Dataverse Migration Tool handles schema-true bulk imports. Advantages: extremely scalable, predictable, ideal for master-data sync. Limits: not real-time, conflict resolution must be designed separately.
When does this fit? Master-data sync between ERP and CRM, BI loading, one-time or periodic data takeovers from legacy systems.
Pattern 04
For in-house APIs or third-party systems without a ready connector: a custom connector wraps the REST interface and makes it directly usable in Power Automate, Power Apps, and Logic Apps. Advantages: reuse, uniform authentication model, fast onboarding of new systems. Limits: self-maintenance on API changes, Power Platform license needed.
When does this fit? In-house systems, niche tools, or third-party systems used multiple times in your setup.
Pattern 05
Dynamics 365 reacts in real time to events — a new opportunity immediately triggers a call to an external system. Dataverse webhooks and Azure Event Grid are the building blocks. Advantages: low latency, loose coupling, scaling via event backbone. Limits: ordering and idempotency guarantees must be actively secured; debugging is more demanding.
When does this fit? Real-time reaction to business events, scaling across many consumers, microservice architectures.
Pattern 06
For BI and analytics scenarios, Microsoft provides Synapse Link for Dataverse — a read access to a copied data base without load on the productive tenant. Direct write database access to Dataverse is not intended and should be consistently avoided. Advantages: high analytics performance, complete historization, Power BI and Fabric friendly. Limits: not for transactional integration.
When does this fit? Reporting, Power BI dashboards, Microsoft Fabric, data lakehouse scenarios.
Ten typical scenarios in the mid-market
Anonymized practice scenarios — we name no customers, but each of these patterns has come up multiple times in our projects or advisory discoveries in the last three years.
Scenario 01
Make email correspondence with contacts visible in Dynamics 365, sync appointments, automatically create activities. Standard connector from Microsoft, supplemented with rules for GDPR-compliant email tracking. Most common stumbling point: configure BCC logic and private-mail separation cleanly.
Scenario 02
Sync customers, items, orders, invoices between CRM and ERP. For Business Central, the Microsoft standard connector covers many standard fields; for SAP Business One and older Dynamics AX estates we rely on Azure Logic Apps with clear mapping tables. Question number one: who owns the master data?
Scenario 03
CTI integration with screen pop, call history, and click-to-call. Microsoft Teams Phone offers the most native integration with Customer Service; Cisco and 3CX are reachable via connectors and complementary adapters. Frequent ask: prioritize calls by SLA and automatically convert them into case tickets.
Scenario 04
When a group already runs ServiceNow or Zendesk, D365 Customer Service doesn't necessarily have to replace it. Instead co-existence: cases are synced bidirectionally, knowledge articles centrally maintained. Realistic and proportionate: not every use case is worth a migration.
Scenario 05
During a HubSpot-to-Customer-Insights-Journeys migration, leads, campaigns, and engagement data have to flow bidirectionally. For Adobe Campaign we use REST API and custom connectors. Important: a clear cutover plan so that marketing automation doesn't fire twice.
Scenario 06
Link documents cleanly to an account, an opportunity, or a case. SharePoint is the obvious choice with native integration; M-Files and ELO are connected via API and custom connectors. Important: keep permission models in sync, otherwise privacy leaks arise.
Scenario 07
Telemetry from machines automatically generates service orders, predictive-maintenance pipelines trigger Field Service dispatch. Azure IoT Hub as event backbone, Connected Field Service as D365 extension. Honest calculation: IoT use cases sound simple but become expensive quickly due to device heterogeneity.
Scenario 08
When time tracking runs in a dedicated tool, time entries and approvals must flow bidirectionally. Toggle and Harvest offer REST APIs that we couple with Project Operations via Azure Logic Apps. Frequent reason: accounting demands posting correctness while the team wants to keep tracking time in the familiar tool.
Scenario 09
Outgoing invoices, incoming payments, master-data reconciliation between Dynamics 365 and German accounting. Datev and Lexware typically use file interfaces; we wrap those in Azure pipelines with a validation layer. Mandatory part: factor in GoBD and retention logic.
Scenario 10
Exchange orders, customers, item master data, and inventory movements between shop and Dynamics 365. For Shopify and Shopware we use REST APIs and webhook events; SAP Commerce is connected via classic middleware. Question number one: who owns price and inventory?
Three architecture approaches
At the architecture level there are three patterns we work with in practice. The choice depends on the number of systems, load, and ops maturity — not the size of your company.
| Approach | When does it fit? | Advantages | Limits |
|---|---|---|---|
| Point-to-point | 2–3 systems, small setups | Quickly implementable, low complexity, low license cost | Doesn't scale, each new system doubles effort, mapping gets distributed |
| Hub-and-spoke (iPaaS) | 3–10 systems, mid-market standard | Central mapping, uniform monitoring, good maintainability, readable workflows | Hub can become a bottleneck, capacity planning required |
| Event-driven (backbone) | 10+ systems, high load, enterprise | Maximum scalability, loose coupling, real-time reaction possible | More complex operational requirements, ordering and idempotency actively secured |
Hub-and-spoke with Azure Logic Apps or Power Automate is the most reliable standard setup in the mid-market. We only take the jump to an event backbone where load profile or business asynchrony forces it.
Six selection criteria
If you put a Dynamics 365 integration out to bid or select a partner, you should check these six points concretely — regardless of whether arades is involved in the end or someone else is.
Ask for concrete examples — not just connector logos. Anyone who can explain Dataverse Web API pagination, batch requests, or plug-in registration-based webhooks in their sleep has the necessary depth.
What workflow complexity has been rolled out to production? Anyone who knows Logic Apps Standard only from demos will have gaps at mid-market load scale. Ask for running workloads, capacity planning, and error rates.
Where do secrets live, what does the audit trail look like, what are data residency and encryption like? For NIS2-relevant customers, an incident response path belongs in every integration architecture too.
What happens when an integration fails? Anyone without a clear answer — Application Insights, dead-letter queues, alerting on error rates, correlation IDs — will live with end-customer complaints in daily operations.
How is an integration carried through dev / test / prod tenants? Solution versioning in Dataverse, Bicep or Terraform pipelines for Azure resources, GitHub Actions or Azure DevOps for the workflows. Without ALM there is no maintainable setup.
Fixed price per pattern or per phase, clear assumptions list, honest notes about what is not included in the fixed price. Anyone offering "effort as needed" pushes the calculation risk fully to you.
Where arades is strong
We rate ourselves against the same six criteria — honestly, without marketing buzzwords, with practice evidence.
We have been building productive REST and GraphQL layers in our own solutions (License Cost Calculator, devonso microservices) for years. The reflex "API clean first, then the UI" is in place — and that's exactly what Dynamics 365 integrations need.
Power Automate, Azure Logic Apps Standard, Service Bus, Event Grid, API Management — we assemble this not from demos but from running setups. Dataverse plug-ins, custom connectors, and webhook registrations are daily tools.
Industry and manufacturing with ERP integration, services with time-tracking and accounting integration, associations and education institutes with DMS and event integration. We know the integration pains of these industries from daily business.
Quality gates, risk reviews, fixed price per phase. In integration projects this is not bureaucracy but the prerequisite for a bidirectional data flow that actually holds up in production.
Our own solutions for education institutes, associations, and license math run on Microsoft Dataverse and Azure integration. We force ourselves to use clean, documented, maintainable integration patterns — and use the same patterns with customers.
After discovery you speak with the same people who build your integration and later care for it. No account-manager layer, no offshore handover. Teams of 2 to 6 people, technically deep in the topic.
Three integration packages
We calculate integration projects as a fixed price per phase. The three packages below are our typical entry formats. The exact investment we calculate after discovery, when load, pattern, and endpoints are clear.
One week, together with your business and IT stakeholders. Data model mapping, trigger logic, load profile, error scenarios. Result: a readable integration blueprint with pattern recommendation and effort estimate for implementation.
A productive integration between Dynamics 365 and a third-party system — typically ERP, DMS, telephony, or marketing. Includes discovery spike, build, test, cutover, and 2 to 4 weeks of hypercare.
A central integration hub for three or more systems, with event backbone, API Management, uniform monitoring, and ALM pipeline. For mid-market groups and growing mid-market companies with a clear multi-system strategy.
Five typical integration mistakes
These mistakes are not rare — they show up in almost every architecture review of an existing integration setup. If you recognize several of them, a review is probably the smaller investment compared to the ongoing daily-operations pain.
01 · "We'll do it with an Excel export." Works for the first few weeks, then doesn't scale. Manual steps are forgotten, versions drift apart, data quality slowly declines. A simple Power Automate flow or a Logic App replaces the Excel hopping quickly and sustainably.
02 · Synchronous call instead of asynchronous. A plug-in in Dynamics 365 that synchronously calls an external API becomes a performance killer — and in the error case it tears the user flow down with it. Writing third-party calls belong in an asynchronous layer: webhook + Service Bus + worker, not in the sync path.
03 · No idempotency. If a message can be processed twice (retry, manual re-drive, duplicate webhook delivery) and no idempotency logic catches it, duplicates arise. Every write operation needs a business idempotency key — without exception.
04 · Error handling as an afterthought. "Works in demo" is not enough. What happens with network outages, with API rate limits, with business-invalid messages? Dead-letter queues, retries with exponential backoff, and a defined re-drive process are mandatory — not optional.
05 · Monitoring missing. If no one notices that an integration has been stalled for three days, the error gets reported by the end customer. Application Insights, alerting on error rates, a dashboard for latency and throughput — that should stand from day one, not only after the first incident.
How an integration runs with us
Workshop with business and IT stakeholders. Data model mapping, trigger logic, load profile, error scenarios documented. Result: integration blueprint with pattern recommendation.
Pattern choice between API-to-API, iPaaS, ETL, custom connector, webhook, or direct database. Decision documented with rationale — even when the desired pattern wasn't the right one.
Implementation in a dev tenant with synthetic data, followed by integration tests against a sandbox tenant. Idempotency, retries, and error handling are mandatory parts.
Production cutover with monitoring, defined rollback path, and 2 to 4 weeks of hypercare. Daily reviews of error rates — we stay on it until it runs quietly.
Documentation, runbook, alerting setup, and knowledge transfer to your team or into our Application Care contract.
Frequently asked questions
A discovery spike of one week is offered as a fixed price from €6,500 net. A standard integration with one third-party system (e.g. D365 Sales and Business Central) typically runs €15,000 to €45,000 net over 4 to 8 weeks. An enterprise integration hub with three or more systems, an event backbone, and monitoring is calculated at €80,000 to €200,000 net over 12 to 20 weeks.
API-to-API for modern SaaS systems with clear REST interfaces, iPaaS / middleware (Azure Logic Apps, Power Automate) for complex workflows with mapping and retry logic, ETL / batch for master data synchronization, custom connectors for in-house APIs, webhooks for real-time reaction, direct database (Synapse Link) for BI and analytics scenarios with read access.
Power Automate is the right choice for manageable volume, simple mapping logic, and citizen-developer-friendly maintenance. As soon as high loads, complex routing, many endpoints, or strict error retry are required, the step to Azure Logic Apps Standard or to Azure Integration Services with Service Bus and API Management pays off.
We plan data residency, transport encryption, secrets management via Azure Key Vault, and audit logs from the first architecture sketch. For NIS2-relevant customers we add monitoring obligations, incident response paths, and supplier documentation to the integration setup. Background: our topic page Compliance & NIS2.
Yes. Via our Knowledge Recovery approach we document existing integrations — even when the predecessor partner is no longer reachable. Result: a readable architecture picture, an error inventory, and a prioritized recommendation about what to keep, refactor, or replace.
After discovery you speak with the same people who will build and later care for your integration. No account-manager layer, no handover to offshore teams. We work in small teams where each person understands both the business logic and the technical implementation.
Every write operation gets a business idempotency key. Faulty messages land in a dead-letter area and are replayed with clear re-drive routines. We also enforce structured logging with correlation IDs across all hops, so that a failed processing can be traced without guesswork.
Yes. For Datev and Lexware we typically use a file-based exchange via their official interfaces, complemented by a validation layer in Azure. This makes outgoing invoices, incoming payments, and master data reconciliation predictable — even when accounting can't keep the pace of the CRM side.
Azure Monitor with Application Insights, Log Analytics for structured search, and alerting on error rates and latency. For Power Automate-centric setups we add the Power Platform admin center and custom dashboards. The goal is always that an integration outage is noticed by us or your team — not by an end customer complaining about a missing invoice.
We have been building integrations around Microsoft Dynamics 365 for over 20 years — beginning with Microsoft CRM 3.0 and today on Dataverse, Azure Integration Services, and Power Platform. Our own solutions (PSA, Intercompany, Education Institutes, License Cost Calculator) force us to use clean, documented, maintainable integration patterns ourselves.
Further reading
Discovery conversation, strategy workshop, architecture review. Before an integration is built, it has to be clear which modules, licenses, and processes actually belong together.
Three introduction packages, 4-phase model, and TCO transparency. Integration parts are typically underestimated in introduction planning — we calculate them openly.
AppSource marketplace, custom solutions, own solutions, plug-ins. Anyone buying an addon buys an integration with it — and should understand its pattern and maintainability.
Why Microsoft Dataverse re-answers the integration question in the mid-market — and when an island solution is still the better answer.
Before the build: tenant structure, data model, security concept, integration mapping. The result is an architecture document any engineering team can build on.
After go-live: predictable contract with monthly flat fee, SLA-based. Includes monitoring, hotfixes, and enhancements of the integration workflows.
30 min · free · no obligation
Tell us about your integration plan — systems, data flow, load, stumbling points. We listen, classify, and tell you honestly which pattern fits and what effort is realistic.
