Hello,
Do NOT sync SQL → BC directly.
Use an external, queue-based integration layer.
---
Recommended setup
SQL Change Tracking
→ Azure integration service (Functions/App Service)
→ Queues (Service Bus / Storage Queue)
→ Business Central APIs
BC is a consumer only, not the orchestrator.
---
Key points (very condensed)
BC Job Queue: Not suitable for 100 tables or near real-time
Queues: Mandatory for scale, retries, ordering, recovery
Sync frequency: Handled outside BC (separate queues/pipelines)
API throttling & locking: Real issues → solved with batching + retries
Change tracking cleanup: Store last synced version externally
Failures: Retry + dead-letter queue + idempotent writes
Validation errors: Pre-validate before calling BC
Monitoring: Azure App Insights / logs, not BC
Initial load: Use RapidStart / Configuration Packages, not APIs
---
Bottom line
External Azure service + queues is the only scalable and reliable approach.
Anything else will break under load.
---
References
https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/
https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/webservices/use-odata-v4-web-services
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-overview
Regards,
Oussama Sabbouh