Dynamics 365 and Azure Integration Services: Scope, Architecture and What to Ask a Firm

What does deep Dynamics 365 and Azure integration actually cover?

A connector that copies contacts every night is not what this page is about. Deep integration means the business processes that cross system boundaries, such as order to cash, quote to invoice, case to field visit or supplier onboarding, run reliably across Dynamics 365 and the other systems involved, with every message accounted for. On Microsoft's stack that work usually combines four layers, and the design decides which layer carries which responsibility.

Where the integration is only between Dynamics 365 Customer Engagement and the Microsoft ERP, the Dataverse-native routes usually come first: the Dataverse connection and virtual tables for Business Central, dual-write and virtual entities for Finance and Operations. Those are covered on our CRM and ERP integration page. This page is about the cases where Azure sits in the middle: third-party systems, high volumes, external consumers, or processes that need queuing, retries and an audit trail of their own.

Which questions should you ask an integration firm before you hire one?

Most integration problems we are asked to look at were decided in the first weeks of the project, by what nobody asked. These are the questions we would want a buyer to put to any firm, including us. A good answer is specific and names a mechanism; a weak answer says the platform handles it.

• Who designs both sides? If one firm configures the CRM, another the ERP and a third the middleware, the record ownership and the conflict rules belong to nobody. Ask who decides which system owns each entity.
• What happens to a message that fails? Ask where it goes (a dead-letter queue, an error table), who is told, and how it is replayed once the cause is fixed, without retyping data.
• Is every operation idempotent? A message that is delivered twice must not create two orders or two payments. Ask how duplicates are detected, for example with an external key or a message ID stored on the target record.
• How is ordering handled? Ask what happens when an update arrives before the create it depends on, and how sessions or sequence checks are used.
• How will you know it has gone quiet? An integration that stops sending messages produces no errors. Ask for alerting on silence, such as no orders received in a business hour, not only on exceptions.
• Where do the logs live and who can read them? Ask for correlation IDs that follow one business transaction across Dynamics 365, Azure and the other system.
• How are secrets and identities handled? Ask for managed identities or service principals, secrets in Azure Key Vault, and no credentials stored in code or in Dynamics 365 configuration.
• How are changes released? Ask for source control, infrastructure as code and deployment pipelines for the Azure resources, and solution or extension pipelines for the Dynamics 365 side.
• Who owns it after go-live? Ask who is on call, who updates the integration when Microsoft releases a change, and what documentation and runbooks you receive.

How does Solzet design a Dynamics 365 integration on Azure?

We start from the business process, not from the tools. For each flow we write down which system owns each record, which events trigger a message, the expected volume and latency, and what a failure costs the business. Only then do we choose the mechanism: an event pushed from Dataverse to a Service Bus topic, a Logic App that orchestrates a multi-step flow, an Azure Function for transformation code that a workflow would make unreadable, or a finance and operations business event that starts a downstream process.

Every design carries the same non-negotiables: messages land on a queue before they are processed, every handler is idempotent, failed messages are dead-lettered with enough context to replay them, and monitoring in Azure Monitor and Application Insights alerts on errors and on silence. When external systems need to call Dynamics 365, we put Azure API Management in front, as described in our guide to exposing Dynamics 365 data through an API gateway.

• Integration inventory and target architecture, with record ownership per entity.
• Message contracts and mappings, versioned in source control.
• Azure resources defined as infrastructure as code and deployed through pipelines.
• Dataverse plug-ins, custom APIs and service endpoints, finance and operations data entities and business events, Business Central APIs and AL extensions, built by the same team.
• Error handling, replay and alerting tested on purpose before go-live, including a deliberate outage of each connected system.
• Runbooks, architecture documentation and a handover session for the people who will run it.

When should a Dataverse plug-in call an external system directly, and when should it hand off to Azure?

Calling an external API straight from a plug-in looks simple and often works in a demo. In production it ties the user's save to the availability and speed of the other system, and it runs inside the Dataverse sandbox with its own limits. Our rule of thumb: a plug-in validates and enriches data inside Dataverse, and anything that depends on another system is handed to Azure Service Bus or a webhook and processed asynchronously. The sandbox rules and the patterns that respect them are in our guide to calling an external API from a Dynamics 365 plug-in.

What if the integrations already exist and nobody trusts them?

Many estates have grown point to point: each new system got its own interface, written by whoever was available, and nobody has the full picture. We start with an assessment of what exists, what each interface does and where data is lost, and we stabilise the flows that matter before changing anything else. Our guide to rationalising point-to-point integrations explains how to untangle them without buying new middleware for its own sake, and our emergency triage guide covers the first days when an integration is losing records silently.

How does integration work with Finance and Operations and Business Central on the ERP side?

Solzet implements the ERP as well as the CRM, so the ERP end of an integration is not a black box handed to another supplier. On Finance and Operations we design data entities, recurring integrations through the Data management framework and business events, and write X++ extensions where a standard entity is not enough. On Business Central we use API v2.0, build custom API pages in AL and subscribe to webhooks for change notifications. The same people decide what the ERP exposes and how Azure consumes it.

How does Solzet deliver and support the integration?

Solzet is a scalable senior consultancy headquartered in Yerevan, Armenia. The work is done by our own senior consultants and full-stack developers, and the people who design the integration are the people who build and support it. Yerevan is on UTC+4, so our working day overlaps most of the European business day and the morning of the US East Coast, which keeps design workshops, incident calls and releases inside your hours.

After go-live you can keep us on support, with monitoring, incident response and updates when Microsoft changes a platform, or take the integration in-house with the documentation, runbooks, pipelines and source code that are yours from the first day. If the CRM itself is not on Microsoft licensing, we integrate a custom-built CRM with Business Central or Finance and Operations the same way.