Connecting your CRM and ERP should mean one thing: your sales team sees accurate, current data from Business Central inside Dynamics 365 Sales, and your finance and operations teams see what’s happening in the pipeline without logging into a second system. In practice, getting there requires a decision most teams underestimate.
Microsoft gives you a native integration path through Dataverse, and it handles the core use case well. But it has real limits. Custom builds offer full control and come with a significant cost and timeline. Third-party platforms sit in the middle: faster to deploy, lower maintenance, but less flexible for edge cases.
This article walks through each path, what it actually covers, where it breaks down, and how to decide which fits your situation.
The core question isn’t which option is most powerful. It’s which option matches your data workload, your team’s capacity, and your timeline.
What you’ll find here:
- How Dataverse works as the default integration layer between Dynamics 365 Sales and Business Central
- What native Microsoft integration handles well and where it falls short
- When custom builds are worth the investment
- When third-party platforms are the faster, lower-risk choice
- A side-by-side comparison to guide your decision
Why Dataverse Is the Default Integration Layer
Microsoft’s current integration architecture places Dataverse at the center. When you connect Dynamics 365 Sales with Business Central, Dataverse is the shared data layer both applications write to and read from. It’s not optional infrastructure; it’s the foundation the native integration runs on.
What Dataverse actually does here
Dataverse plays two distinct roles depending on how you configure the integration:
Data sync (physical replication): Records are copied between Business Central and Dataverse on a schedule. Changes in one system propagate to the other via job queue entries. For a deeper look at how replication works across systems, see Rapidi’s data replication guide. This is the traditional approach and the one most setups use for entities like customers, contacts, and items.
Virtual tables (live access without replication): Business Central data is exposed directly in Dataverse without copying it. A sales rep querying inventory availability or customer credit limits sees the live Business Central record. The data never leaves Business Central; Dataverse just presents it.
“Virtual tables present Business Central rows in Dataverse while the data remains in Business Central.” — Microsoft Documentation
The virtual table approach is significant because it removes the sync delay and eliminates duplicate records for read-heavy use cases. For a sales rep checking whether stock is available before committing to a delivery date, live access is more useful than a record that was last synced two hours ago.
What the setup requires
Both environments must be in the same Microsoft tenant. You install the Business Central Virtual Table app from AppSource, configure the Dynamics 365 Connection Setup page in Business Central, and map integration tables to define which entities sync in which direction.
Standard out-of-the-box mappings cover:
- Accounts (Dataverse) to Customers (Business Central)
- Contacts
- Products and price lists
- Opportunities
- Sales orders
These mappings are configurable. You can adjust sync direction, field mapping, and job queue frequency. You cannot easily add entities outside the standard set without custom development or a third-party tool.
What sales reps actually see
Once the integration is live, Dynamics 365 Sales users get access to Business Central data from inside their CRM:
- Real-time inventory levels and item availability
- Customer credit limits and payment history
- Pricing and price list data
- Posted invoices and order status
According to Microsoft’s integration documentation, this combined setup gives sales reps the financial and inventory context they need to make accurate commitments without switching systems. That’s the core value proposition of the native path.
Where Native Microsoft Integration Works Well (and Where It Doesn’t)
The native path is the right starting point for most Microsoft-only environments. It’s included in your existing licenses, it’s maintained by Microsoft, and it covers the standard CRM-to-ERP data flows without additional tooling.
Where it works well
Native integration is a strong fit when:
- Both Dynamics 365 Sales and Business Central are your only business systems
- Your core need is syncing customers, contacts, items, and orders between the two
- Sales reps need live visibility into inventory, pricing, and credit limits
- Your team has internal capacity to configure and maintain the Dataverse connection
- You’re operating in a single Microsoft tenant
For these scenarios, the native path avoids additional software cost, keeps data governance inside the Microsoft ecosystem, and uses infrastructure your team already knows.
Where it breaks down
Native integration has documented limitations that become real problems at scale or in more complex environments:
Offline access: Virtual tables require a live connection to Business Central. If your sales team works in areas with unreliable connectivity or needs to work offline, virtual tables don’t help. Physical sync (data replication) is the workaround, but that reintroduces sync delays and duplicate record risk.
Heavy reporting workloads: Microsoft’s own community guidance notes that virtual tables are not a suitable replacement for Fabric or Lakehouse scenarios. If your reporting team needs to run complex queries or aggregate large datasets, querying Business Central through virtual tables creates performance pressure on your live ERP environment.
Non-standard entities: The standard integration table mappings cover a defined set of entities. Adding custom Business Central tables or non-standard Dynamics 365 Sales entities requires custom development work, which moves you out of the native path and into custom territory.
Multi-system environments: If your business also runs Salesforce, SAP, a third-party logistics platform, or a separate e-commerce system, the native Dataverse integration doesn’t extend to those. You’d need separate integration work for each connection.
Duplicate record management: When Dataverse sync is active, the same customer can exist as a record in both systems. Microsoft uses a coupling mechanism to match records, but managing duplicates, handling conflicts, and cleaning up mismatched data requires active administration. These are among the most common data integration challenges teams run into after go-live.
Key takeaway: Native integration is not a set-and-forget solution. It works well within defined boundaries, but it requires ongoing admin attention and breaks down when your data environment extends beyond the core Microsoft stack.
When Custom Integration Is Worth It
Custom-built integrations give you full control over data mapping, sync logic, error handling, and business rules. That control comes at a cost: custom builds are slower to implement, more expensive to maintain, and carry more risk when either system is updated.
What custom development actually covers
A custom integration typically involves:
- Writing API calls to Business Central’s OData or REST APIs (see Rapidi’s guide to API Pages in Dynamics 365 Business Central for a technical overview)
- Building transformation logic to handle field mapping, data type differences, and business rules
- Setting up retry logic, error handling, and alerting
- Managing authentication, security, and performance at scale
- Maintaining the integration when Microsoft releases updates to either platform
This is not a one-time project. Business Central and Dynamics 365 Sales both release major updates twice a year. A custom integration needs to be tested and updated with each release cycle, which adds ongoing developer time to the total cost.
When custom makes sense
| Scenario | Why custom fits |
|---|---|
| Highly specific business logic | Standard mappings don’t support complex pricing rules, approval workflows, or multi-entity relationships |
| Non-standard data structures | Your Business Central setup has significant customizations that no off-the-shelf connector covers |
| Regulatory or security requirements | Data must stay on-premises or in a specific region with custom handling |
| Large-scale data volume | You need fine-grained control over batching, paging, and performance at high transaction volumes |
Business Central’s API handles large datasets using OData paging via @odata.nextLink, which means custom integrations need to account for paginated responses when pulling bulk data. This is a technical detail that catches teams off guard if they underestimate the scope.
The real cost of custom builds
Implementation costs for Business Central projects broadly range from $30,000 to $300,000 or more depending on complexity. Integration-specific custom development adds to that baseline. The ongoing maintenance burden is what most teams underestimate: every API change, schema update, or new business requirement means developer time.
“Custom integration logic, data mapping, retries, security, and performance are fully tailored to your business and Dynamics 365 processes.” — Microsoft Dynamics 365 Integration Services guidance
Custom builds are the right answer when your requirements are genuinely unique and no standard tooling fits. They’re the wrong answer when the real driver is a preference for control rather than a documented technical requirement that other options can’t meet.
When Third-Party Integration Platforms Are the Faster Path
Third-party iPaaS integration platforms sit between native and custom. They offer pre-built connectors for both Dynamics 365 Sales and Business Central, a configuration layer for mapping and transformation, and managed infrastructure for running and monitoring the integration.
The tradeoff is straightforward: you get faster time to value and lower maintenance overhead, in exchange for an ongoing subscription and less flexibility on highly custom logic.
What third-party platforms handle that native doesn’t
The practical advantages over native Microsoft integration are most visible in three areas:
Multi-system connectivity: If your environment includes systems beyond the Microsoft stack, a third-party platform extends the integration to cover them. A single platform can connect Dynamics 365 Sales, Business Central, a Salesforce instance, a third-party warehouse system, or an e-commerce platform without separate integration projects for each pair.
Pre-built templates: Rather than configuring integration table mappings from scratch, most platforms ship with pre-built templates for common flows: customer sync, order creation, invoice status, inventory updates. These reduce setup time significantly compared to building from the Dataverse connection setup page.
Managed error handling and monitoring: Native Dataverse sync relies on job queue entries and requires manual investigation when sync fails. Third-party platforms typically provide dashboards, alerting, and retry logic out of the box, which reduces the admin burden on your team.
Upgrade resilience: When Microsoft updates Business Central or Dynamics 365 Sales, the platform vendor updates their connectors. Your integration doesn’t break because your team missed a schema change.
When third-party platforms make sense
- You don’t have internal developer capacity to build and maintain a custom integration
- Your environment includes systems outside the Microsoft stack
- You need the integration running in weeks, not months
- Your team has been burned by a fragile custom integration before
- You want pre-built templates for standard flows with room to configure
- You need visibility into sync health without digging through job queue logs
What to look for in a platform
Not all iPaaS tools are equal for this use case. When evaluating options, focus on:
| Evaluation criterion | What to check |
|---|---|
| Pre-built connectors | Does the platform have native connectors for both Business Central and Dynamics 365 Sales, not just generic REST adapters? |
| Template coverage | Which standard flows (customers, orders, invoices, inventory) are pre-built vs. requiring custom configuration? |
| Error handling | How does the platform surface failed records, and what’s the retry behavior? |
| Upgrade policy | Who is responsible for updating connectors when Microsoft releases a new API version? |
| Data residency | Where does data pass through during transformation, and does that meet your compliance requirements? |
The subscription cost for a third-party platform is an additional line item, but it replaces developer time for build and maintenance. For most mid-market businesses without a dedicated integration developer, that trade is worth it.
Comparing the Three Paths: Native, Custom, and Third-Party
Here’s a direct comparison across the dimensions that matter most for this decision.
| Native (Dataverse) | Custom build | Third-party platform | |
|---|---|---|---|
| Setup time | Days to weeks | Months | Weeks |
| Upfront cost | Included in license | High (development) | Low to medium |
| Ongoing cost | Admin time | Developer maintenance | Subscription fee |
| Standard entity coverage | Customers, contacts, items, orders, opportunities | Anything you build | Pre-built templates + configurable |
| Custom entity support | Requires dev work | Full | Depends on platform |
| Multi-system support | Microsoft stack only | Any system with an API | Broad, depends on connectors |
| Offline access | No (virtual tables) | Yes, if built | Depends on platform |
| Reporting workloads | Not recommended | Full control | Depends on platform |
| Upgrade maintenance | Microsoft-managed | Your team | Vendor-managed |
| Error visibility | Job queue logs | Custom alerting | Dashboard + alerts |
Licensing costs to factor in
Integration doesn’t add a separate Microsoft SKU, but the licenses for both platforms are a real cost to plan around. Current pricing as of 2026 (verify against Microsoft’s pricing page for your tenant):
- Dynamics 365 Sales Professional: $65/user/month
- Dynamics 365 Sales Enterprise: $105/user/month
- Dynamics 365 Sales Premium: $150+/user/month
- Business Central Essentials: $80/user/month
- Business Central Premium: $110/user/month
- Business Central Team Member: $8/user/month (read-only access)
Business Central Premium (at $110/user/month) includes manufacturing and service management on top of the Essentials feature set. If your integration use case centers on sales order flow and inventory, Essentials at $80 may be sufficient. Premium is the right tier when you need manufacturing or service management data flowing into the integration.
Note on pricing: Microsoft licensing terms change. The figures above reflect widely cited 2026 pricing following the October 2025 price increase, but always confirm current pricing through your Microsoft partner or the official Dynamics 365 pricing overview before budgeting.
The decision in plain terms
Go native if: You’re running Dynamics 365 Sales and Business Central as your only business systems, your data flows map to the standard entities, and you have internal capacity to configure and monitor the Dataverse connection.
Go custom if: Your requirements are genuinely unique, you have specific regulatory or data residency constraints, or your Business Central environment is heavily customized in ways no standard connector covers.
Go third-party if: You need the integration live quickly, your environment includes systems beyond the Microsoft stack, or you don’t have a dedicated integration developer to build and maintain a custom solution.
Common Questions About Dynamics 365 Sales and Business Central Integration
Can Dynamics 365 Sales and Business Central share the same customer records?
Yes, with caveats. The native Dataverse integration uses a coupling mechanism to match records between the two systems. An Account in Dynamics 365 Sales maps to a Customer in Business Central. When the coupling is set up correctly, changes in one system propagate to the other. The challenge is managing conflicts: if a sales rep updates a customer’s address in Dynamics 365 Sales at the same time a finance admin updates it in Business Central, the sync logic needs a defined rule for which system wins. This is one of the most common sources of data quality issues in native integrations. See Rapidi’s data integration challenges guide for how teams typically handle record conflicts and duplicate management after go-live.
Do you need Dataverse to integrate Dynamics 365 Sales with Business Central?
For the native Microsoft integration path, yes. Dataverse is the required shared layer. You can’t connect Business Central directly to Dynamics 365 Sales without it. Third-party platforms and custom builds can bypass Dataverse by connecting to Business Central’s APIs directly, but the native integration is Dataverse-dependent. Microsoft’s Integrating Business Central with Microsoft Dataverse documentation covers the full setup requirements. For a broader look at how Rapidi connects the two platforms, see the Dynamics 365 Business Central and Sales integration solution page.
What’s the difference between virtual tables and data sync in this integration?
Data sync copies records between Business Central and Dataverse on a schedule. Virtual tables expose Business Central data in Dataverse in real time without copying it. Virtual tables are better for read-heavy use cases where freshness matters (inventory availability, credit limits). Data sync is better when you need the data available offline or when downstream Dataverse apps need to query it independently of Business Central’s availability. Rapidi’s data replication guide covers how physical sync works across systems and when replication is the right model. Microsoft’s virtual table overview explains the live access architecture in detail.
Can you integrate Business Central with Salesforce instead of Dynamics 365 Sales?
Yes. Business Central’s APIs are accessible to any integration platform or custom build. Connecting Business Central to Salesforce is a common use case, and several third-party platforms offer pre-built connectors for both. The native Dataverse integration is specific to the Microsoft stack; it doesn’t extend to Salesforce. If your CRM is Salesforce, a third-party platform or custom build is the right path. Rapidi covers this in detail in the Salesforce and Microsoft Dynamics 365 Business Central integration guide. Rapidi covers this in detail in the Salesforce and Microsoft Dynamics 365 Business Central integration guide.
How long does the native integration take to set up?
For a standard configuration covering the default entity mappings, most teams complete the setup in a few days to a couple of weeks. For context on the different integration patterns available and how setup complexity varies by approach, Rapidi’s data integration techniques guide is a useful reference. The timeline extends when you need to clean up existing data before coupling records, configure custom field mappings, or resolve duplicate records across both systems. Complex environments with customized Business Central setups take longer.
Is Power Automate a viable integration option?
Power Automate can handle simple, event-driven flows between Dynamics 365 Sales and Business Central, such as creating a Business Central customer when a new account is created in Dynamics 365 Sales. It’s not a full integration platform. For a comparison of Microsoft’s native automation tools against third-party options, see Rapidi’s breakdown of Microsoft Azure Logic Apps integration. For bulk data sync, complex transformation logic, or high-volume transactional flows, Power Automate is not the right tool. It works well as a complement to the native Dataverse integration for specific automation tasks.
Before You Commit to the Integration Budget
The native Microsoft integration through Dataverse is a solid starting point for most businesses running Dynamics 365 Sales and Business Central together. It covers the core data flows, gives sales reps live access to ERP data, and requires no additional software cost. It’s also not the right answer for every situation.
Custom builds earn their cost when your requirements are genuinely outside what standard tooling covers. Third-party platforms earn their subscription when speed, multi-system coverage, and lower maintenance overhead matter more than maximum flexibility. The decision comes down to three questions. If you want a broader view of how CRM and ERP data flows connect across the full revenue cycle, Rapidi’s guide to the lead to invoice process is a useful companion read.
The decision comes down to three questions:
- Are your data flows standard, or do they require logic that native mappings can’t support?
- Is your environment Microsoft-only, or do you need to connect systems outside the stack?
- Does your team have the capacity to build and maintain a custom integration, or do you need a managed path?
Answer those honestly before you commit to an approach. The most common mistake is defaulting to custom development because it feels like the most thorough option, when a native or third-party path would have delivered the same business outcome faster and at lower total cost.
For a deeper look at how a pre-built integration platform handles the Dynamics 365 Sales and Business Central connection, Rapidi’s Dynamics 365 Business Central and Sales integration solution is worth evaluating alongside your native and custom options.
The post Dynamics 365 Sales Integration with Business Central: Native, Custom, or Third-Party? appeared first on CRM Software Blog | Dynamics 365.