Integrator for Microsoft Dynamics
Integrating the Microsoft Dynamics API into your system
We wire Dynamics 365 into your product, ecommerce, or field ops: usage lands in Sales, the order is pushed into the ERP, an incident becomes a support case. Dynamics stays the system of record.
- Senior product team
- ERP connectors in production
- scoping through to monitoring
Why work with a Microsoft Dynamics integrator and what can be connected?
Microsoft Dynamics 365 covers CRM (Sales, Customer Service, Field Service) and ERP (Finance, Supply Chain, Business Central). You integrate it so your product, ecommerce or field ops live on it: usage lands on the account, a channel order becomes an ERP document, a field incident becomes a support case, without a parallel spreadsheet. Dynamics stays the system of record; we connect around it, we do not replace it.
What Dynamics changes in your platform
Product usage landed in Sales
Sales sees real usage on the account record. No more weekly export, no more call to production asking where the customer stands.
Field incident becomes a support case
An incident in the mobile app creates the case and the work order. The Dynamics SLA applies; field and support share the same record.
Ecommerce order pushed into the ERP
The cart creates the order in Finance & Supply Chain. Price and availability stay the ERP's, not a storefront cache.
SME invoicing from Business Central
Customers, items and entries stay in BC. Your vertical SaaS attaches instead of rebuilding accounting or a parallel spreadsheet.
What it changes in your product
Engineering in service of a measurable outcome: usage in Sales, orders in the ERP, support without Excel.
Sales, F&O or BC: the right scope
« Dynamics » is not enough to price a project. We identify the application (Sales, Finance & Operations or Business Central) before estimating. You buy the connector that fits your flow, without a scope surprise.
Sales sees the product
Usage, contract and incident land on the account record. No more calls to production asking where the customer stands.
Price and stock stay the ERP's
Order, stock and invoice stay in Dynamics. The portal shows what the ERP decides, it does not recompute the price. One business truth.
A connector that belongs to you
Code delivered, documented, credentials in a vault. You are locked into neither a black box nor a partner badge.
How we wire Dynamics into your platform
Scoping
Where Dynamics enters your product: Sales, Customer Service, F&O or Business Central. Cloud or on-premises. Dual-write yes or no. Without the app name, an estimate means nothing.
Mapping
Units, VAT, journals, teams, F&O company. Upsert keys. Signed off with the business before the first channel or field flow.
Development and testing
A connector wired into your product, ecommerce or field ops. Retries, bounded batches. F&O: live traffic or package by volume. BC: API v2, AL API if a custom field.
Monitoring
Quota reading, circuit-breaker, retry queue. You see an incident before it breaks the sales channel or invoicing.
What the API brings to your platform
- Land usage in Sales
- Accounts, contacts, opportunities and custom tables via Dataverse. Enough to power the sales record from your product.
- Push the order into the ERP
- Finance & Operations exposes order, stock and party entities. Price and availability stay ERP logic.
- Import volume without saturating
- Data management for bulk F&O loads. On-premises, that is the supported channel. Live traffic is not a warehouse.
- Attach a SaaS to Business Central
- REST API v2.0 for customers, items, entries. A custom field requires a dedicated AL API, not an extension of the standard API.
The vocabulary of a Microsoft Dynamics integration
- Dataverse
- The store for Customer Engagement apps (Sales, Customer Service, Field Service). Web API OData v4 v9.2. It is not F&O, it is not Business Central.
- Finance and Operations
- The ERP (Finance, SCM, Commerce, HR depending on the deployment). Root /data, public AOT entities, Data management for volume. Company = dataAreaId.
- Business Central
- The SME ERP. Distinct REST API v2.0. A custom field means copied AL and a custom API, you do not extend the standard API.
- Entra ID
- The directory (formerly Azure AD). App registration, delegated or application permissions. A « Microsoft 365 » app does not reach Dataverse. Admin consent often required.
- Service protection
- Dataverse cap per user, per web server, 5 minutes: 6,000 req, 20 min CPU, 52 concurrent. Distinct from the 24 h licence entitlement.
- Dual-write
- F&O to Dataverse bridge, when the client has enabled it. A Power Platform maker can read the ERP without a copy. Confirm per project, it is not magic.
The real constraints of a Microsoft Dynamics integration
« Dynamics » names three stacks
Dataverse, F&O and Business Central share neither API nor data model. A brief saying « Dynamics integration » without the app name cannot be priced.
Two Dataverse quotas, not one
Protection (429, 5 minutes, 6,000 req) is not entitlement (daily allocation by licence). A $batch cuts calls but increases execution time.
F&O: company (dataAreaId) and $expand
Forgetting cross-company=true = silently incomplete data. $expand stops at the first level. On-premises, only the Data management package API is supported.
BC: no extension of the standard v2 API
A custom field means copying the AL and publishing a custom API, with signing and environments. It is not one more field on customers.
Dataverse or Finance and Operations
Two products, two APIs. Business Central is a third family, REST v2.0, to scope separately. Mixing them in a quote makes the project unpriceable.
| Criterion | DataverseSales, CS, Field Service | Finance & OperationsFinance, SCM, Commerce |
|---|---|---|
| Product | Customer Engagement, data in Dataverse | F&O ERP (Finance, Supply Chain, Commerce) |
| Access channel | Web API OData v4, /api/data/v9.2/ | OData v4 /data, plus Data management package |
| Authentication | Entra ID, Dataverse permissions | Entra ID, same stack as the F&O server |
| Limits | 6,000 req / 5 min, 52 concurrent, entitlement separate | OData page max 10,000, volume via packages |
| Common trap | Slow plug-ins that burn the 20-minute window | Forgotten company, $expand beyond one level |
| On-premises | Same Web API on the deployed Dataverse org | Data management package only |
| The right case | CRM, cases, field service, Power Apps on Dataverse | Order, stock, invoice, ERP party |
Business Central (API v2.0) is neither Dataverse nor F&O. We claim no Solutions Partner Business Applications designation. We integrate through the public APIs cited on Microsoft Learn.
What we measure on a Dynamics project
The other ERPs we integrate
The choice follows whichever ERP you already run, rarely the technology.
Microsoft DynamicsIntegrating the Microsoft Dynamics API into your systemThis page
OdooOpen ERP: API over the whole object model, Python modules if needed.
SAPS/4HANA Cloud on published OData, BTP beside it, not a single API.
DivaltoFrench ERP for industrial SMEs: Infinity for writes, OData for reads.We combine Microsoft Dynamics with
The stack that surrounds Dataverse, F&O and BC on our projects.
Microsoft Dynamics integration: your questions
First map where Dynamics enters your product, and name the application: Sales, Finance and Operations, or Business Central. Auth Entra ID, Dynamics permissions. On Sales: upsert, retry, bounded batches. On F&O: company correctly targeted, live traffic or package by volume. On BC: API v2, AL API if a custom field. The real difficulty is not the HTTP call, it is that product usage, the channel order and support share the same Dynamics truth, without a parallel spreadsheet.
It depends on the application, the touchpoints and the volume. Landing usage in Sales is priced differently from an ecommerce bridge to F&O or from a Business Central AL API. Two things weigh heavily: the app diagnosis (Sales is not Finance), and F&O volume, which switches from live traffic to packages. Dual-write, if already there, changes the design but is not a prerequisite. We scope the app and give a firm estimate.
Dataverse is the store for Customer Engagement apps: Sales, Customer Service, Field Service. API: /api/data/v9.2/, protection 6,000 req / 5 min. F&O is the large-account ERP: Finance, Supply Chain, Commerce. API: {host}/data plus packages; on-premises, packages only. Business Central is the SME ERP, REST API v2.0, published OpenAPI, custom fields via a copied AL API. Dual-write can expose F&O entities in Dataverse, if the client has enabled it. A Microsoft Dynamics integrator who talks about a single API has not opened the tenant yet.
The Solutions Partner Business Applications designation is useful for the functional rollout, licences and Power Platform. For a connector on the public APIs, what counts is command of Dataverse, F&O /data and the BC v2 API, plus Entra ID. We claim no Microsoft designation: we integrate through the APIs documented on Microsoft Learn, and we are glad to work with the partner already running your org.
Two caps. Service protection, per user and per web server, 5-minute sliding window: 6,000 requests, 20 minutes cumulative execution, 52 concurrent requests (floor). Response 429 with Retry-After, codes 0x80072322 / 0x80072321 / 0x80072326. Headers x-ms-ratelimit-burst-remaining-xrm-requests and x-ms-ratelimit-time-remaining-xrm-requests. A $batch up to 1,000 operations cuts the number of calls but increases execution time. Entitlement (daily allocation by Power Platform licence) is separate: a batch does not bypass it. Search API: 1 req/s/user. Plug-ins do not count as protection requests, but their CPU adds to the triggering request.
A Microsoft Dynamics project?
Let's talk. 30 minutes to identify where Dynamics touches your product or channel, the app (Sales, F&O, Business Central), then tell you honestly what is feasible.
Discuss my Dynamics project