Dynamics 365 Integration, Built for the Version You Actually Run
“We run Dynamics 365” can mean very different things. It might be Sales and Customer Service on Dataverse, Finance and Supply Chain on a separate engine, or Business Central with APIs of its own. Each connects to the rest of your business through a different entry point, and choosing the wrong one can slow or weaken the integration.
Dynamics 365 combines CRM and ERP: pipeline, service cases, marketing journeys, ledger, inventory, and orders. This is very valuable when the data stays current across your store, SAP, Salesforce, reporting, and support systems.
PenguinPeak Technologies builds those connections. We start by identifying which Dynamics 365 apps you run and which method suits each data flow, then design around Microsoft’s service limits and security model. We serve businesses in New Zealand, India, the United States, Abu Dhabi, and Australia.
Four Doors Into Dynamics 365, and What We Build Behind Each
Door one: customer engagement applications
The Sales, Customer Service, Marketing, and Field Service solutions use Dataverse, so we connect via its Web API. Standard tasks include syncing accounts, contacts, leads, and cases with websites, helpdesks, and marketing tools, or running Dynamics 365 in parallel with Salesforce and HubSpot.
Door two: Finance, Supply Chain Management and Commerce
These apps expose OData and data entities, accept bulk packages through the Data Management Framework, and publish business events. We use them to bring in store orders, push out stock levels, and connect your ledgers to platforms such as SAP and your online store.
Door three: Business Central
It has its own set of APIs, so we treat it separately. Common implementations include online sales, bank feeds, payroll, field apps, and NAV/GP to D365BC migrations.
Door four: The Microsoft layer
Integration between Dynamics 365 and Power BI via Power Automate flows, plus other Azure services like Logic Apps and Service Bus, helps Dynamics 365 connect to chatbots that can respond to queries based on real-time data.
Which Method for Which Job
Dual-write
near-real-time master data (customers, products, vendors) shared between finance and operations apps and Dataverse. Best for master data, not heavy transaction volume.
Web API and OData
reading/writing at a single-record level in either direction. Scalable, but limited by the service.
Data Management Framework
batch read/write import/export in financial/operational applications. Volume processing, not real-time.
Business events
an external application is notified of an event as it occurs, such as an invoice. You must configure and manage the receiving endpoint.
Power Automate
approval processes, notifications, and synchronization processes. Fast to create, but hard to control as processes multiply.
Azure Logic Apps/Service Bus with custom code
high-volume, multiple-step/queued processes with the need for retries and tracking.
Synapse Link/Fabric Feeds
reporting into Power BI. Reporting only, no operational write-back.
Bring Us the Messy Part
Send us the Dynamics 365 connection that gives you problems, whether it is missing orders, finances that conflict with sales, or bad reporting. We will tell you why there is a problem and what we can do to fix it.
Start a Dynamics 365 Scoping Chat
What a Dynamics 365 Specialist Changes
Most integration platforms treat Dynamics 365 as a single connector. We start with an application audit, since what works for Sales integration will not work for Finance. This saves time down the road.
Constraints are placed in the architecture, not the bug list. Dataverse rate limits abusive clients, and we throttle requests during design review rather than finding out the limit in production.
Security follows the Microsoft pattern. Every integration gets its own app registration and a limited application user, so no integration runs on a personal account.
You also keep the keys. We hand over source code, mapping documents, and credentials at project close, and you can opt for a support plan.
Service Limits We Plan Around
Microsoft has documented the default Dataverse service protection limits that are applicable for each user and web server:
- 6,000 requests over a 5-minute sliding window
- 20 minutes of total execution time during the same window
- Concurrent requests should not exceed 52
If you exceed the limits above, you will get a 429 error code and a Retry-After response header. Limits vary by environment, so we check them at the start. Licensing is equally important. Dual write has no additional cost, but users and applications that use the data need proper Dynamics 365 and Dataverse licenses.
Frequently Asked Questions
It includes Sales, Customer Service, Marketing, and Field Service apps, as well as Finance, Supply Chain Management, Commerce, and Business Central apps. These are not on one platform. The first two apps are based on Dataverse and use its Web API, while the others use OData, data entities, and business events, and Business Central uses different APIs. We select the correct entry point for each app before coding.
This will depend on the job you have in mind. Dual write is recommended for master data between Finance and Operations applications and Dataverse applications. Use Web API and OData for custom system-to-system integration. Power Automate is for simple workflow and notification jobs. Large volumes and complicated logic would require custom code on Azure. Most jobs typically use two of these three.
Yes, it can sync in real time, though not always. Dual write syncs data between the finance and operations applications and Dataverse very quickly, and business events can alert other systems as soon as an invoice is posted or an order is finished. For batch processing, like nightly product imports, the Data Management Framework is more appropriate. We match the speed to the use case, since real-time processing of everything adds no value but increases cost and complexity.
They can if you ignore them. The default limits are 6,000 requests and 20 minutes within five minutes, and the maximum number of simultaneous requests is 52 or more. You will get a 429 response code with a Retry-After header in case of breaking these limits. We regulate the request rate and implement retries according to environment-specific requirements and limits.
All integrations use an individual Microsoft Entra ID app registration with OAuth 2.0 authentication and connect to the Dynamics 365 application user with a minimal set of assigned security roles. We don’t hardcode secrets; we store them in a vault. We test the integration in your sandbox, audit all API calls, and consider your Microsoft region. Once the project is complete, we stop having access, and you retain the application registration and credentials. If you select a support plan, then we’ll have just that level of access required by the support plan.
Yes. We connect Dynamics 365 to other ERPs such as SAP, CRMs such as Salesforce or HubSpot, stores on Shopify or Magento, and older Dynamics AX, NAV, or GP systems during a move. Each link starts with a written data map, so both systems agree on what a customer, product, or order actually is.
The scope drives both. Key considerations include how many systems are involved, how many entities are moved, whether data moves one-way or bi-directionally, the volume to be transferred, and how many custom fields your Dynamics 365 project has. Environments also play an important role, as we’ll work in Development, Testing, and Production. We give a firm estimate after the discovery phase.
Get a Free Quote
Complete the Form Below and Get Your Quote in 24 Hours !
