Last updated: November 5, 2026
By ZapAI Team
Business Central and Dynamics 365 Sales connect through Microsoft Dataverse using an integration that ships inside Microsoft Dynamics 365 Business Central, so sellers see ERP customers, items, prices, orders and invoices without a second login, and order processors get Sales orders without retyping them. No connector to buy. As of November 2026 the setup is still assisted, still driven by the job queue, and still full of decisions nobody makes until something breaks.
The Business Central and Dynamics 365 Sales integration couples records through Dataverse and syncs them on job queue schedules. Customers, contacts, items, prices, sales orders and posted invoices sync out of the box, and Business Central should stay master for anything financial.
Setup takes an afternoon. Living with it is the hard part. Most guides screenshot the setup toggles and stop, skipping what shows up months later, like a Sales edit that waits half a day to reach Business Central or an order stuck because a salesperson was never linked to a Dataverse user.
This guide covers the sync mechanics, field ownership, sales order modes, pricing, multi-company setups, licensing, alternatives, monitoring and a checklist. Every product fact was checked against Microsoft Learn and Microsoft licensing pages on November 5, 2026, with Business Central on version 29. Still choosing the CRM? Our Dynamics 365 Sales consultants can help first.
How Does the Business Central and Dynamics 365 Sales Integration Work?
Under the hood, Business Central connects to a Dataverse environment, imports an integration package into Sales, and links matching records through couplings. Integration table mappings decide which tables and fields move and in which direction. Job queue entries run the sync.
Five pieces do the work.
- A Dataverse connection, set up per environment. New integrations must go through Dataverse, per Microsoft’s guide to integrating with Dynamics 365 Sales.
- An integration package the setup guide imports into Sales, adding security roles and the tables that map each Business Central company to a Dataverse business unit
- Integration table mappings and field mappings. Each sets a direction.
- Couplings, which link one Business Central record to one Dataverse row
- Job queue entries that sync changed records, every 30 minutes by default
Coupling comes first. A customer and an account sync only once coupled, and Sync. Only Coupled Records is on by default, so uncoupled records are ignored. Couple by hand, with match-based coupling, or with a full synchronization.
Full sync deserves a warning. Microsoft’s Dataverse connection guide says to run it only when one side holds the data and you want one row per record, because running it when both systems already have customers creates duplicates. When data exists in both apps, the setup guide itself recommends No synchronization. Listen to it.
Timing is murkier. Event-based synchronization, on by default, syncs coupled Business Central changes automatically, yet Microsoft says the integration doesn’t guarantee real-time consistency. Plan for minutes. Not seconds.
And here’s the trap almost nobody mentions. Each sync job has an inactivity timeout, so when a run finds no changes the job goes on hold, by default for 12 hours on customers and contacts and 24 hours on items and posted invoices. Business Central wakes a held job only when something changes in Business Central. A change made in Sales doesn’t wake it, per the job queue synchronization page. A seller’s address fix can sit for hours.
What Syncs Out of the Box?
Customers, vendors, contacts, salespeople, currencies, units of measure, items, resources, customer price groups, sales prices, opportunities, sales orders, order notes and posted sales invoices all have default mappings. Directions differ. That’s where planning starts.
| Business Central | Sales or Dataverse | Direction | Default filter or note |
|---|---|---|---|
| Salesperson/Purchaser | User | Dataverse to Business Central | Licensed, non-integration users only |
| Customer | Account | Both ways | Relationship Type Customer, active, not blocked |
| Vendor | Account | Both ways | Relationship Type Vendor, active, not blocked |
| Contact | Contact | Both ways | Person contacts assigned to a company |
| Currency | Transaction Currency | Business Central to Dataverse | One way only |
| Unit of Measure | Unit Group | Business Central to Sales | One unit per group unless Unit Group Mapping is on |
| Item | Product | Both ways in the mapping table, Business Central to Sales in the job list | Product Type Sales Inventory |
| Resource | Product | Same as items | Product Type Services |
| Customer Price Group | Price List | Business Central to Sales | Synced as Sales price lists |
| Sales Price | Product Price List | Business Central to Sales | Customer price group prices only |
| Opportunity | Opportunity | Both ways | Salesperson Code sets the owner in Sales |
| Sales Order Header | Sales Order | Both ways once bidirectional sync is on | Released orders only |
| Posted Sales Invoice header and lines | Invoice and Invoice Product | Business Central to Sales | Sync everything the invoice uses first |
That table combines Microsoft’s standard Dataverse table mapping with the Sales-specific list. Two Microsoft pages disagree on items. The Sales mapping table lists items and resources as syncing both ways, while the default job queue list shows them flowing from Business Central to Sales only. We treat Business Central as the item master either way.
Some extras aren’t default. Older Microsoft release notes describe mappings for payment terms, shipment methods and shipping agents, so check your Integration Table Mappings page before assuming they’re there. Customer balance and total sales reach the Sales account through a separate statistics job, and Automatically Synchronize Item Availability refreshes stock for coupled items every 30 minutes. Half an hour old, though.
Which System Should Own Which Data?
Business Central should own anything that posts to the ledger or prices an order, and Sales should own the pipeline. Customer master data is the one real negotiation. Our advice is one owner per field, not per table.
Bidirectional mappings sound friendly. They also breed conflicts. When a seller and someone in receivables edit the same customer in their own apps, the next sync can’t pick a winner, and the record sits skipped until a person resolves it. So we narrow directions per field.
| Data | Suggested owner | Why, in ZapAI practice |
|---|---|---|
| Credit limit, payment terms, blocked status, tax setup | Business Central | Finance controls them, and they affect posting |
| Account name and addresses | Pick one, usually Business Central once a customer exists | Bill-to and ship-to drive invoices and shipments |
| Phone, website, industry | Sales | Sellers keep these current |
| Contacts | Sales | Sellers meet the people |
| Items, units and prices | Business Central | Costing and price lists live there |
| Opportunities and pipeline | Sales | Business Central opportunities are basic |
| Released orders, shipments, invoices, payments | Business Central | Sales should read them, not write them |
Each field mapping carries its own direction, so a bidirectional customer mapping can still send credit limit one way only. Set conflict rules as well. Microsoft’s table and field mapping guide lets you choose, per mapping, whether Business Central sends its update or takes the Dataverse one when both changed, and whether to restore a deleted record or remove the coupling. Leave those blank and every conflict gets resolved by hand.
One more rule comes from the integration’s design. Changes made by the integration user account don’t sync at all. Microsoft says plainly not to use that account to edit integrated records. Believe it.
How Do Sales Orders and Quotes Move Between the Two Apps?
You pick one of two modes, and they’re mutually exclusive. Bidirectional Synch of Sales Orders moves orders both ways and keeps sellers current on price, tax and shipment changes. Enable Legacy Sales Order Integration moves submitted orders from Sales to Business Central only.
| Question | Bidirectional Synch of Sales Orders | Enable Legacy Sales Order Integration |
|---|---|---|
| Direction | Sales to Business Central and back | Sales to Business Central only |
| How an order becomes eligible | Seller sets status to Submitted, which locks the lines | Seller uses Submit, which locks the whole order |
| Status on arrival | Released | Released |
| Fixing a mistake | Reopen as Open in Business Central or Active in Sales, edit, resubmit | Correct it in Business Central |
| What flows back to Sales | Price, tax amount and expected shipment date changes | Mapped header fields such as Last Shipment Date |
| Extra requirement | Sales order archiving, switched on for you | Administrator credentials for Sales |
Our default is bidirectional for new setups. Sellers see back-office price and tax changes, and archived order versions help when a customer disputes what was agreed.
Either way, Sales changes once back-office order processing is on. Microsoft’s article on how to enable sales order processing integration says the Create Invoice button disappears from orders, submitted orders become read-only, and Sales skips price recalculation on submitted orders. Invoices come from Business Central now. Tell sellers before go-live.
Details that decide whether orders flow
- Couple customers, units of measure, currencies, customer price groups and items before the first order.
- Write-in products need a fallback item or resource on Sales & Receivables Setup. Don’t couple it.
- Orders waiting on a prepayment arrive as Open.
- Shipped orders show Fulfilled in Sales.
- Microsoft says only orders that began in Sales sync back periodically. Test that.
Quotes run through Automatically Process Sales Quotes. An activated quote in Sales becomes a Business Central quote, revisions archive the prior version, and a won quote becomes an order only when a matching order is submitted. Posted invoices land in Sales as Billed and switch to Paid once payment is applied, per Microsoft’s guide to managing customers with Dynamics 365 Sales.
How Should You Handle Prices and Units of Measure?
Keep pricing in Business Central and sync only what Sales can represent. The new pricing experience syncs simple sales price lists. Quantity breaks, discount lines and lists that allow updating defaults stay behind.
Pricing is where we see the most surprise. In the new experience, which every customer since 2020 release wave 2 gets by default, Business Central syncs a price list only when five conditions hold.
- Allow Updating Defaults is off.
- Price type is Sale.
- Amount type is Price.
- Lines are items or resources.
- No minimum quantity.
So picture a distributor with volume breaks at 10, 50 and 100 units. Sales gets the base price. Sellers quote it. Order processors fix it. Everyone’s annoyed. Decide up front whether Sales quotes carry final or indicative prices, since Microsoft’s advice for pricing that doesn’t fit is to customize the integration.
Two smaller traps sit beside it. Item sync creates a price list in Sales automatically, and Microsoft says not to edit it by hand. And if someone changes a product price in Sales and that item lands on a Business Central order, Business Central creates a new sales price list for each order. Keep price edits in Sales locked down for sellers, or the price list page fills up fast.
Unit groups
By default a Business Central unit of measure maps to a Sales unit group that holds only one unit. Sell by the case and the each? Then turn on Unit Group Mapping on the Dynamics 365 Connection Setup page.
Do it before go-live. Switching it on deletes the existing item mappings, and since Sales won’t change a product’s unit group, Microsoft’s steps have you uncouple items, retire the old products and let Business Central create new ones. With open quotes, that’s a weekend project.
How Do Multi-Company Setups Work?
Several Business Central companies can sync with one Dataverse environment. Each company gets its own business unit and owner team, records carry a company ID, and you turn on Multi-Company Synchronization Enabled on each table mapping that should respect it.
Per Microsoft’s data ownership models page, updated October 14, 2026, each company you enable creates a business unit directly below the root, named with the company name and ID, plus an owner team whose name starts with BCI. Then you pick an ownership model.
- Team. The company’s default owning team owns new accounts and contacts. Simpler.
- Person. The Dataverse user coupled to the record’s salesperson owns it. An unlinked salesperson causes a sync error.
Documents trip people up. With the checkbox on, order, quote and opportunity mappings consider only rows carrying the current company’s ID, so sellers must set the company on each document or it never syncs, while for master data the same checkbox removes the company filter instead. Microsoft also recommends the From Integration direction and number prefixes when customer numbers might collide.
Our view on shared customers. Decide whether Sales shows one account or two before anything syncs. Test it in a sandbox first.
What Licenses and Capacity Does the Integration Need?
Sellers need a Dynamics 365 Sales license, Business Central users need Business Central licenses, and the integration’s own application user needs none. Synced rows also use Dataverse database capacity, which pools across your Dynamics 365 licenses.
Microsoft’s Business Central licensing guidance is blunt about it. Sales integration requires a Dynamics 365 Sales license. Business Central alone doesn’t cover CRM users.
| License | List price, November 2026 | Notes |
|---|---|---|
| Business Central Essentials | $80 per user per month | Enough to run the setup guide |
| Business Central Premium | $110 per user per month | Qualifies for the Sales Enterprise attach |
| Dynamics 365 Sales Professional | $65 per user per month | Core sales force automation |
| Dynamics 365 Sales Enterprise | $105 per user per month | Includes Copilot in Dynamics 365 |
| Dynamics 365 Sales Premium | $150 per user per month | Adds 1,000 Copilot Credits per user per month |
| Sales Enterprise attach | $20 per user per month | Only for users whose base license is Business Central Premium |
| Integration application user | No license | Created automatically during setup |
Prices come from Microsoft’s pricing pages, paid yearly. One conflict. The licensing guidance shows Business Central Premium at both $100 and $110, and the pricing page says $110. We use $110.
Attach pricing helps when one person wears both hats. A Premium user adding Sales Enterprise pays $130 a month instead of $215. Full tier math lives in our Dynamics 365 Sales pricing guide and our Business Central pricing breakdown.
Capacity is the quieter cost. Microsoft’s Dataverse capacity page, updated October 26, 2026, describes staged overage rules. Past 100% of entitled capacity, creating, copying and restoring environments gets blocked. After 30 days, affected sandboxes drop into administration mode, and the Business Central connection fails against any Dataverse environment in administration mode. A full storage pool can quietly break sandbox testing.
When Should You Use Virtual Tables, Business Events or Power Automate Instead?
Use the standard sync for shared master data and the order flow. Reach for virtual tables when Sales users need live Business Central data without copying it, business events when something in Business Central should start a process elsewhere, and Power Automate or custom AL for the gaps.
| Option | What it does | Status, November 2026 | Good for |
|---|---|---|---|
| Standard Dataverse sync | Copies coupled records on schedules and events | Generally available | Customers, contacts, items, prices, orders, invoices |
| Virtual tables | Reads and writes Business Central data live from Dataverse, no copy | Available through the Business Central Virtual Entity app | Order history or open balances on a Sales form |
| Business events | Notifies Dataverse or other systems when something happens in Business Central | Preview | Order released, invoice posted, customer blocked, credit limit exceeded |
| Power Automate Business Central connector | Triggers and actions on Business Central records | Premium connector, business event trigger in preview | Alerts, approvals, small one-off syncs |
| Custom AL or third-party connectors | Extends the mappings or replaces the sync | Varies | Tiered pricing, custom objects, large multi-company groups |
Virtual tables are the real-time option Microsoft points to. Data stays in Business Central, but anyone reading it through a virtual table must also exist as a Business Central user. Charts and attachments aren’t supported yet.
Events are still a preview, per Microsoft’s business events overview. The built-in catalog covers moments like a sales order released or an invoice posted, and notifications fire only after the transaction commits.
Power Automate fills smaller gaps. The Business Central connector reference lists record triggers, approval triggers and a business event trigger in preview, with throttling at 300 API calls per connection every 60 seconds. Fine for alerts. Wrong for bulk sync. Our Power Automate use cases roundup covers where flows pay off.
Custom work is for when the standard mappings almost fit. Since version 28, new and custom Dataverse tables appear in the mapping lookup without a developer, and version 29 made mapping new Dataverse fields generally available, per the version 29 release notes. The mapping guide still labels adding mappings a preview. Two pages disagree.
How Do You Monitor the Sync and Fix Common Errors?
Check three pages weekly. The Integration Synchronization Log shows each run and its failures, Integration Synchronization Errors gives the error text, and Coupled Data Synchronization Errors shows skipped records you must fix or retry.
Skipped records are the quiet failure. Microsoft’s synchronization status page says that for each record with an error, sync is skipped until someone fixes it, and the usual causes are two people changing the same data in both apps or a deletion on one side only. Nothing pings you. Records just stop moving.
From that page you can retry records, synchronize to choose which side wins, restore or delete records after a one-sided deletion, or remove the coupling.
| Symptom | Likely cause | Fix |
|---|---|---|
| Account edits in Sales arrive hours late | Job on hold for inactivity, and Sales changes don’t wake it | Shorten the inactivity timeout on that job queue entry |
| Records listed as skipped | Changed on both sides, or deleted on one | Set conflict rules, then Retry All |
| Accounts fail with a salesperson error | Person ownership with an unlinked salesperson | Couple salespeople to Dataverse users first |
| Duplicate accounts after go-live | Full sync run while both systems had data | Match-based coupling, then merge duplicates |
| Connection fails during setup | Dataverse environment in administration mode | Take it out of administration mode |
| Auditing stopped on synced tables | Integration package import reset auditing | Turn auditing back on for affected tables |
| Custom mappings vanished after reconnecting | Reconnecting through Dataverse reapplies defaults | Document custom field mappings before reconnecting |
The auditing row comes from Microsoft’s Dataverse integration page, which warns that importing the base integration package can switch off auditing that another package had turned on. Check it the day you connect.
When Shouldn’t You Integrate Business Central and Sales?
Skip it when Business Central’s own relationship management covers your sales process, when nobody will own the data rules, or when quotes depend on pricing the standard sync can’t carry. A bad sync is worse than none.
Built-in relationship management in Business Central covers contacts, segments, interactions, opportunities and campaigns. For three sellers, that may be plenty.
Poor fits for the standard integration, in our view.
- Tiny sales teams already working inside Business Central
- Companies committed to another CRM. Read our Dynamics 365 CRM vs Salesforce comparison first.
- Quantity breaks or contract discounts that sellers must quote exactly
- Sales environments reshaped by other apps. Microsoft warns that apps changing the standard Sales data model, like Project Service Automation, can break the integration.
- Reporting-only needs. Dataverse Link to Fabric fits better.
Agents shift the math a little. If the real goal is faster order entry from emailed requests, the Sales Order Agent inside Business Central might do it with no CRM at all, as our Business Central agents guide explains.
What Does a Setup Checklist Look Like?
Clean the data, decide ownership, connect in a sandbox, couple instead of full syncing when both sides hold data, then monitor weekly. That’s ZapAI’s working order. Not a Microsoft rule.
Before you connect
- Licenses assigned. Sales for sellers, Business Central for ERP users.
- Field ownership agreed and written down
- Salespeople linked to Dataverse users
- Duplicates merged on both sides
- Unit Group Mapping decided now. Not later.
- Dataverse base currency set up in Business Central
- Pricing scope agreed for Sales quotes
Connect and couple
- Sandbox first.
- Certificate authentication in each environment and company
- Ownership model chosen before sync starts
- Match-based coupling where both systems hold data
- Sales order mode picked
- Audit settings rechecked.
Run and monitor
- Conflict rules set on each mapping
- Inactivity timeouts reviewed
- Skipped records checked
- Dataverse capacity under 85%
- Copied companies reconnected. Copying clears their integration settings.
For the wider project around it, our Business Central implementation guide and our Dynamics 365 CRM implementation checklist cover phases, testing and go-live.
What Could Change After Ignite 2026?
Maybe nothing for this integration. Ignite runs November 17 to 20, 2026, in San Francisco, and in our experience the headlines go to Copilot and agents, not sync plumbing.
Where to watch. Since September 2026, Business Central changes appear on the AI at Work roadmap instead of release plans, as our guide to the Dynamics 365 release wave changes explains. We’ll recheck pricing sync rules and business events status after the event.
Wrapping Up
Out of the box, both apps already know how to talk. The integration runs through Dataverse and covers customers, contacts, items, prices, orders and invoices. What it won’t do is decide who owns each field, which prices Sales can show, or who checks the skipped records every week. Those calls are yours.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Business Central consultants and Dataverse services team set up the connection, design field ownership and pricing sync, and clean up broken couplings. Talk to us about your Business Central and Sales integration, and we’ll review your mappings, ownership rules and sync logs before anything changes.
Questions Teams Ask About the Business Central and Sales Integration
Do we need a third-party connector to integrate Business Central with Dynamics 365 Sales?
No. The integration is built into Business Central and runs through Dataverse. You need licenses on both sides, a Dataverse environment with Sales, and an administrator to run the assisted setup guide.
How frequently does data sync between Business Central and Sales?
Every 30 minutes by default through job queue entries, plus event-based sync for coupled records changed in Business Central. Jobs that find no changes pause for 12 or 24 hours, and edits in Sales don’t wake them, so shorten timeouts if sellers edit master data.
Can sales orders sync in both directions?
Yes, with Bidirectional Synch of Sales Orders. Orders submitted in Sales arrive in Business Central as Released, and price, tax and shipment date changes flow back. It can’t run alongside Enable Legacy Sales Order Integration.
Do sellers need a Business Central license?
Not to work in Sales. Microsoft’s licensing guidance says Sales integration requires a Dynamics 365 Sales license, and the integration’s application user needs no license. Anyone reading Business Central data through virtual tables must exist as a Business Central user.
Why are some records not syncing?
Usually they’re skipped. A record changed in both apps, or deleted in one, stays skipped until someone resolves it on the Coupled Data Synchronization Errors page. Conflict rules on each table mapping can settle those automatically.
Does the integration sync price lists with quantity discounts?
Not with the standard sync. In the new pricing experience, only sale price lists with item or resource lines, amount type Price, no minimum quantity and Allow Updating Defaults off qualify. Tiered pricing needs customization.
Can several Business Central companies share one Sales environment?
They can. Each company maps to its own business unit and owner team in Dataverse, and you turn on Multi-Company Synchronization Enabled per table mapping. Sellers must set the company on orders, quotes and opportunities so those documents sync.