A sales rep calls a customer about a renewal. The customer says they cancelled last week, and the billing system agrees. Dynamics 365 still shows the account as active, so the call is awkward and the forecast is wrong.
Most Dynamics 365 rollouts run into this within a few months. Dynamics holds the accounts and deals, while the rest of the business lives somewhere else: orders in a store, usage in a Postgres database, invoices in an ERP. A Dynamics 365 connector is what keeps those copies in agreement.
Below you will find why the data drifts, what the Dynamics API allows, four ways to connect it, and what to check before you choose.
Why the Numbers in Dynamics 365 Never Match Your Other Tools
The mismatches are small, and they add up:
- A customer updates a billing address in your web store, and Dynamics 365 still shows the old one.
- Sales closes a deal in Dynamics 365 Sales, but the order never reaches the ERP or the product database.
- Sales and finance report different revenue figures because each team reads a different copy of the data.
- Someone patches the gap with a weekly CSV export, which is already out of date by the time it is imported.
The root cause is usually the integration design. Many integrations push data in one direction on a schedule, so a change made on the other side has no path back into Dynamics 365. The more teams edit the same customer, order or product records, the faster the two sides disagree.
What Dynamics 365 Actually Lets You Read and Write
Dynamics 365 stores its customer engagement data in Microsoft Dataverse. Dataverse exposes that data through a Web API that implements OData version 4.0, so any tool or script that connects to Dynamics 365 is ultimately calling this API. Three details matter when you design a sync.
1. Ask only for what changed
Dataverse supports change tracking. When you send a request with the Prefer: odata.track-changes header, the response includes a delta link, and a later request to that link returns only the records that were created, updated or deleted since the last read. Without it, an integration has to re-read whole tables to find what changed. Microsoft’s documentation on change tracking describes the full flow.
2. Writing back is where mappings break
Records are created and updated through standard HTTP methods such as POST and PATCH. Custom tables (also called entities), lookup fields and choice columns all need to be mapped correctly, and a mapping that works on day one can break when an admin adds a custom column.
3. The API will tell you to slow down
Dataverse protects itself with service protection API limits. Per user, per web server, the limit is 6,000 requests within a five-minute sliding window, plus 20 minutes of combined execution time in that window. When an application goes over, the Web API returns a 429 Too Many Requests error with a Retry-After header telling the caller how many seconds to wait. Microsoft’s service protection limits documentation explains the exact behavior. Any integration that syncs large tables needs to respect these limits or it will stall.
Four Ways to Connect Dynamics 365 (and What Each One Costs You)
1. Power Automate: great until you need both directions
Microsoft’s own tools work well when a flow starts inside the Microsoft ecosystem, such as posting a Teams message when an opportunity closes. They are built around triggers and actions. Keeping an entire table in step with an external database in both directions means you still have to build and maintain the matching, conflict and retry logic yourself.
2. Custom code: a two-week project that never ends
Writing your own integration gives you full control. It also means you own pagination, retries after a 429 response, delete handling, schema changes and monitoring. An integration that starts as a two-week project tends to become a permanent maintenance task for one developer. For agencies and consultants who build these integrations for clients, that maintenance tail is also the hardest part to bill, and this guide on turning one-off integration projects into recurring revenue shows how teams price it.
3. ETL: perfect for dashboards, blind to changes made elsewhere
Extract, transform and load pipelines copy Dynamics 365 data into a warehouse, which is the right choice for reporting and dashboards. These pipelines move data one way on a schedule, so they do not update Dynamics 365 when something changes elsewhere.
4. A Dynamics 365 connector with two-way sync: both sides stay current
A Dynamics 365 connector built for two-way sync sits between Dynamics and the other system and keeps records matched in both directions. It handles the change detection, API limits and retries described above, and it lets you decide which side owns each field, so an ERP can own credit terms while Dynamics 365 owns the sales stage. This is the best fit for operational data that several teams edit every day.
Eight Things to Check Before You Pick a Dynamics 365 Connector
Not every connector behaves the same way. Before you commit, check these points:
- True two-way sync. Changes made in either system should reach the other, with clear rules for what happens when both sides edit the same record.
- Field-level control. You should be able to set which fields each system can write, and mark others as read-only.
- Change and delete handling. The connector should pick up updates and deletes without re-reading full tables.
- Rate limit handling. It should back off on a 429 response and resume on its own instead of failing.
- Custom tables and fields. Your Dynamics 365 setup is probably customized, and the connector should follow those customizations.
- Latency you can predict. Know whether changes arrive in seconds or in scheduled batches.
- You need logs and alerts that show what synced, what failed and why.
- Look for encryption in transit and at rest, role-based access, and independent audits such as SOC 2.
Where Dynamics 365 Sync Pays Off First
1. Ecommerce store: the rep sees the order before the customer calls
Customers and orders live in the store, while sales and support teams work them in Dynamics. Syncing keeps contact details, order status and purchase history current in both places, so a sales rep sees the latest order before the next call.
2. Product database: real usage inside the CRM record
SaaS teams often keep accounts, plans and usage in Postgres or another database. Syncing that data with Dynamics 365 lets account managers see real usage next to the CRM record, and lets product changes update the CRM automatically.
3. Data warehouse: reports and operations on the same numbers
For analytics, teams replicate Dynamics data into a warehouse and combine it with other sources. This is where ETL and connectors often work together: the warehouse handles reporting, and the connector keeps operational systems aligned.
4. Finance system: quotes and invoices that match
Quotes, invoices and payment status need to match between CRM and finance. Syncing those objects removes the manual re-entry that often leads to billing disputes.
Six Steps to Take Before You Connect Anything
- List the systems you need to connect and the tables in each one (accounts, contacts, orders, products).
- Decide the source of truth for every important field, for example which system owns the email address and which owns the payment terms.
- Choose the direction and latency each object needs. Reporting data can wait for a batch, while order status usually cannot.
- Test in a sandbox environment with a copy of real data before you touch production.
- Plan for deletes and schema changes, including what should happen when someone adds a custom field.
- Set up alerts so a failed sync reaches a person quickly, not a customer.
FAQs – Questions People Ask About Dynamics 365 Connectors
What is a Dynamics 365 connector?
A Dynamics 365 connector is a tool that links Dynamics 365 to another application or database and moves records between them. Some connectors only export data from Dynamics, while others keep both systems updated with two-way sync.
Does Dynamics 365 have an API I can use?
Yes. Dynamics 365 data stored in Dataverse is available through the Dataverse Web API, which follows the OData version 4.0 standard. You can call it directly, or use a connector that calls it for you.
What are the Dynamics 365 API limits?
Dataverse applies service protection limits per user: 6,000 requests and 20 minutes of combined execution time within a five-minute sliding window. When you exceed them, the API returns a 429 error with a Retry-After value, and the integration needs to wait before it retries.
How is a connector different from ETL?
ETL copies data on a schedule, usually in one direction into a warehouse, and is built for reporting. A two-way connector keeps operational records in step between systems, so a change in either one shows up in the other.
Do I need custom code to connect Dynamics 365 to my database?
Not necessarily. Custom code gives you full control, but you also have to maintain retries, deletes and schema changes. A connector takes over that work, which is why teams often switch to one once a custom integration becomes hard to maintain.
Which Dynamics 365 data should I sync first?
Start with the objects that cause the most manual work: usually accounts, contacts and orders. Once those are stable, add products, invoices and custom tables.
