# Dynamics 365 Custom Integration: When Standard Connectors Aren't Enough Microsoft markets Dynamics 365 as a platform that connects to everything. And for basic scenarios — syncing contacts between Business Central and Outlook, posting sales orders to a Teams channel, t... ## Dynamics 365 Custom Integration: When Standard Connectors Aren't Enough Custom D365 integration development — OData APIs, custom APIs, Azure Service Bus, virtual entities, and dual-write — for Business Central and Finance & Operations environments where Power Automate and AppSource connectors cannot handle your data volume, transformation logic, or legacy system connections. Built by a Zeeland, MI team with 20+ years connecting ERP systems to everything else. --- ## Our Process 1. **D365 Integration Assessment & Architecture Selection (1–2 Weeks)** — We audit your D365 environment (Business Central, Finance & Operations, or both), catalog every system it needs to exchange data with, and map the data flows — what moves where, how often, in what volume, and with what transformation logic. For each integration point, we evaluate which D365 API surface is the right fit: custom API pages, OData data entities, DMF batch jobs, custom services, dual-write, or virtual entities. We assess your non-D365 systems for API availability, database access, and file export capabilities. Deliverable: an integration architecture document with the specific D365 API layer, messaging pattern (direct, queue-based, or pub/sub), and estimated cost for each connection. 2. **API Contract & Data Mapping Specification (1–2 Weeks)** — Before writing integration code, we define the data contract for every connection. This means field-level mapping between D365 entities and target systems, data transformation rules (unit conversions, account code translations, currency handling, entity splitting and aggregation), conflict resolution logic for bidirectional syncs, error handling behavior (retry policies, dead letter routing, alerting thresholds), and authentication flows (OAuth 2.0 for Azure AD-protected D365 APIs, API keys for third-party systems, certificate-based auth for legacy connections). For Business Central custom APIs, we write the AL API page specifications. For F&O integrations, we define data entity configurations and DMF job parameters. 3. **Integration Development & Sandbox Testing (3–8 Weeks)** — We build integrations in priority order against your D365 sandbox environment. Business Central custom API pages are developed and deployed as extensions. F&O data entities, custom services, and business events are developed in the appropriate D365 development environment. Middleware components — Azure Functions, Service Bus configurations, legacy system connectors — are built and deployed to Azure or your infrastructure. Every integration gets unit tests, integration tests against sandbox data, batch processing tests at 2–5x your expected volume, error injection testing (simulated API failures, timeout scenarios, malformed data), and performance benchmarking. A straightforward Business Central to WMS integration takes 3–4 weeks. A multi-system F&O integration with legacy bridging, Service Bus event routing, and complex transformation logic takes 6–8 weeks. 4. **Parallel Running & Data Validation (1–3 Weeks)** — Integrations run alongside your existing processes — manual or otherwise — for a validation period. Automated reconciliation compares integration output against your current data movement methods transaction by transaction. This is where we catch the edge cases that sandbox testing cannot simulate: unusual transaction types, end-of-period posting anomalies, timezone mismatches on international transactions, D365 number sequence gaps, and vendor-specific API quirks that only surface with production data shapes. Your team continues their current workflow unchanged until integration accuracy is verified. For high-volume integrations (50,000+ records per batch), validation includes throughput testing under production load to confirm that batch windows complete within your operational requirements. 5. **Production Cutover & Ongoing Monitoring (Ongoing)** — After validation, we cut over to automated integration, configure monitoring dashboards in Azure Monitor or your preferred observability platform, set up alerting for failures and anomalies (processing time deviations, error rate spikes, volume drops that suggest upstream issues), and provide 30 days of hypercare support. Ongoing maintenance covers D365 version update compatibility testing (Microsoft releases major updates twice yearly and cumulative updates monthly), third-party API change monitoring, Azure Service Bus health management, performance tuning as transaction volumes grow, and emergency response for integration failures. Maintenance runs $750–$3,000/month per integration cluster depending on the number of connected systems, transaction volume, and SLA requirements. --- ## Frequently Asked Questions ### When should we use custom D365 integration instead of Power Automate? Power Automate is the right tool for low-volume, simple integrations between D365 and modern SaaS platforms — syncing a few hundred records between Business Central and your CRM, posting notifications to Teams when invoices are approved, or triggering simple workflows from D365 business events. Move to custom integration when any of these conditions apply: your batch sizes exceed 5,000 records per sync cycle and you are hitting Dataverse API throttling limits; your data transformations require conditional logic beyond simple field mapping (entity splitting, multi-currency aggregation, chart of accounts translation); you need sub-second real-time sync rather than 5-15 minute polling; you need enterprise error handling with dead letter queues, partial completion tracking, and resumable batch processing; you are connecting to legacy systems that have no Power Platform connector; or your Power Automate licensing costs (Premium at $15/user/month plus AppSource connector fees) are approaching the cost of a custom build that you own outright. The breakeven point is typically 12-18 months. Companies processing more than 10,000 transactions per day across 3+ integration points almost always save money with custom integration within the first year. ### What is the difference between OData endpoints and custom API pages in Business Central? Business Central exposes OData v4 endpoints for every published page and query object. These endpoints work, but they are designed for ad-hoc data access, not for production integrations. Page-based OData endpoints expose every field on the page (including fields your integration does not need, adding payload overhead), break when someone modifies the page layout, carry UI metadata that inflates response sizes, and do not support custom computed fields or server-side transformation logic. Custom API pages, introduced in Business Central's modern development model, are AL objects designed specifically for integrations. They expose exactly the fields you define, support custom computed fields (so you can return aggregated or transformed data without post-processing), are versioned independently of page layouts (page changes never break your integration), support complex OData filtering and expansion, and can enforce server-side validation logic that rejects bad data before it enters Business Central. If you are building a one-off data export, standard OData endpoints are fine. If you are building a production integration that needs to run reliably for years, custom API pages are the only serious option. We build every Business Central integration against custom API pages as a baseline practice. ### How do you handle high-volume batch processing in Finance & Operations? Finance & Operations provides the Data Management Framework (DMF) specifically for high-volume batch operations, and it is dramatically more efficient than per-record OData calls. The DMF package API lets you submit a file (CSV, XML, or Excel) containing hundreds of thousands of records as a single batch operation. F&O processes the file server-side using its own data import/export engine, which handles validation, transformation, and posting in parallel across multiple threads. A 500,000-record inventory import that would take days via per-record API calls completes in minutes through DMF. We build DMF-based integrations using the recurring integration pattern: an Azure Function prepares the data package, submits it to F&O via the DMF package API, monitors the job status, and handles success/failure at the batch level (with record-level error reporting from F&O's execution log). For near-real-time scenarios where DMF's batch nature is too slow, we use OData-bound data entities with change tracking — F&O's change tracking provides delta queries so we only process records that have changed since the last sync, keeping per-request volume low enough to stay within API limits while maintaining close-to-real-time freshness. ### What role does Azure Service Bus play in D365 integrations? Azure Service Bus is a fully managed enterprise message broker that serves as the central nervous system for D365 integrations in multi-system environments. Instead of building point-to-point connections between D365 and every other system (which creates a brittle spaghetti architecture), Service Bus provides a message backbone that decouples producers from consumers. When a sales order is created in D365, a message is published to a Service Bus topic. Your WMS, your CRM, your invoicing system, and your BI warehouse each have their own subscription to that topic with independent filters — they each receive and process the event at their own pace, in their own way, without knowing about each other. If one consumer is down, its messages queue until it comes back. If a message fails processing, it moves to a dead letter queue for investigation instead of being lost. Service Bus handles duplicate detection (critical when D365 business events occasionally fire twice), sessions for ordered delivery (essential for financial postings where sequence matters), and scheduled delivery for messages that should not be processed until a specific time. For D365 specifically, Business Central can publish to Service Bus via Azure Functions triggered by webhooks or change notifications, and Finance & Operations has built-in support for publishing business events directly to Service Bus endpoints. We size Service Bus tiers based on message volume and throughput requirements — Basic for simple scenarios, Standard for most production workloads, and Premium for high-throughput environments that need dedicated capacity. ### What are virtual entities and when do they make sense for D365 integration? Virtual entities (also called virtual tables) let you expose external system data inside Dataverse as if it were a native Dataverse table — without actually copying the data into Dataverse storage. Users, Power Apps, Power BI reports, and D365 Customer Engagement apps can read and interact with the external data using standard Dataverse interfaces. The data is fetched from the source system in real time via a custom data provider that you build and register. Virtual entities make sense for reference data that lives in an external system and is read frequently but updated infrequently: product catalogs from a PIM system, customer data from an external CRM, inventory levels from a WMS, pricing from a CPQ tool. Instead of building a batch sync that copies this data into Dataverse every hour (and dealing with staleness, storage costs, and sync failures), virtual entities serve it live. They do not make sense for high-frequency transactional queries, for data that needs to participate in Dataverse-native features like business rules and workflows that require local data, or for scenarios where the external system's API latency would make the Dataverse UI feel slow. We build custom virtual entity data providers in C# that connect to your external systems, handle authentication, implement caching for performance (so every Dataverse grid refresh does not hit the external API), and support Dataverse's standard query operators (filtering, sorting, pagination) translated into the external system's query language. ### How much does custom D365 integration cost compared to Power Automate? The cost comparison depends on scope and timeline. For a simple Business Central integration with one external system at low volume (under 1,000 records per day, straightforward field mapping, no legacy systems), Power Automate with the D365 connector is cheaper: you are looking at $15/user/month for Power Automate Premium licensing and minimal development time to build the flows. Total first-year cost might be $5,000-$10,000 including setup. For the same scenario, custom integration runs $15,000-$25,000 upfront plus $750-$1,500/month in maintenance. Power Automate wins on simple scenarios. The calculus reverses at scale. A mid-market D365 F&O environment with 5-10 integration points, 50,000+ records per day, legacy system connections, and complex transformation logic will cost $80,000-$200,000 for custom integration (build plus first year of maintenance). The Power Automate alternative is not really an alternative at that scale — you would spend $30,000-$50,000 trying to build it in Power Automate, hit the throttling and transformation limits we described, then spend another $80,000-$200,000 rebuilding it custom anyway. We have done this exact rebuild for three D365 clients in the past two years. If you know your integration requirements are complex, building custom from the start saves the cost of the failed Power Automate attempt. We scope every integration individually with a fixed-price estimate after the discovery phase, so you know exactly what you are paying before development starts. --- **Canonical URL**: https://freedomdev.com/solutions/dynamics-365-custom-integration _Last updated: 2026-05-12_