Syncing WooCommerce orders to Dynamics at high volume

If your code calls Dynamics while the customer waits at checkout, then every slow response from Dynamics becomes a slow checkout, and any outage on its side can look like a store problem. The order should be saved in WooCommerce and put in a queue, and a background worker does the rest. Now Dynamics being unavailable means a backlog, and the store keeps selling.

On WordPress, check how the queue actually runs. WooCommerce’s docs say webhooks process in the background through wp-cron by default, and wp-cron is usually triggered by site traffic. On a busy store, run the scheduler from a real server cron instead, so a backlog doesn’t depend on page visits.

Webhooks retry, workers crash after sending and before recording, and someone will click “resend” eventually. Your integration has to expect the same order more than once.

• On Business Central, put the Woo order number in externalDocumentNumber, and check for it before creating a sales order. Consider also adding a lock in your own queue, so two workers can’t pick up the same order.
• On Dataverse, an alternate key with upsert gives you this directly.
• Record what was sent and what came back, against the order, so you can answer questions six months later.

The default limits are generous, until a promotion or a backfill arrives.

• Business Central allows 6,000 OData requests in five minutes per user, 5 processed at a time and 100 connections. Extra requests wait up to 8 minutes, and then return a 503. Over the connection or rate limit, you get a 429. An order with many lines can take many requests, so count them. $batch takes up to 100 operations.
• Dataverse has 6,000 requests, 20 minutes of execution time and 52 concurrent requests per user on each web server. Microsoft’s advice is to let the server tell you how much it can handle, and to obey Retry-After.
• Finance is throttled by server resource use, with a 429 and Retry-After. It also lets you set which integrations are throttled first.

So limit concurrency on your side, starting low and rising until you see throttling. On a 429, wait for the time stated, and don’t count that as a failed attempt. Retrying at once only extends the wait, and Dataverse states that continued demanding requests make it longer.

• Temporary failures, such as a timeout, 429 or 5xx, go back into the queue with an increasing delay.
• Data failures, such as an unknown SKU or a missing tax code, won’t fix themselves. Retrying wastes your quota and hides the problem. They go to a named person, with the order and the reason.
• Validate before sending. A bad postcode caught in your queue is a two-minute fix. Caught days later in Dynamics, it is an investigation.

Don’t let one bad order block the rest. If processing must stay in order for a customer, hold that customer’s orders and let everyone else’s through.

The most dangerous failure is the one nobody sees. WooCommerce disables a webhook after repeated failures, five by default, and after that no message tells you orders have stopped. A daily job fixes this:

1. List yesterday’s paid orders from WooCommerce, using modified_after.
2. List yesterday’s sales documents from Dynamics.
3. Report anything missing, anything with a different total, and how old the oldest queue item is.
4. Resend what is missing, which is safe because of rule two.

Then alert on what matters: queue age, count of held orders, and whether the webhook is still active. A dashboard nobody looks at doesn’t count.

• Tell whoever runs Dynamics when it is, since large posting batches on their side can slow you too.
• Run a load test in the sandbox using realistic line counts. Note that the sandbox may have different limits.
• Check that your queue can drain faster than orders arrive at peak, and work out how long the backlog would take.
• Hold back non-essential sync, such as bulk product updates, until the campaign ends.

On the Belgian beverage retailer, the integration sits inside a maintenance engagement alongside PHP upgrades, plugin updates, monitoring and backups every two hours. That arrangement fits, because a WooCommerce update, a plugin update or a Dynamics change can each affect the sync. Someone has to own that, and it needs retesting after each one. See WooCommerce maintenance for how we run it.

The field mapping guide covers what travels, and the integration service covers how we would build it for you.