On a discovery call a couple days ago, a growing consumer goods company was weighing HubSpot as their CRM and wanted to connect it to Business Central. Their goal was clean and reasonable: if a salesperson adds a distributor in the field, or a sales order comes in, they wanted Business Central to be the version they could trust. One source of truth, as they put it.
That goal is right. How you get there is where the decisions live, and they are worth understanding before you sign anything.
Bidirectional sync sounds great until it isn't
The instinct is to have data flow both ways: create something in either system and have it show up in the other. The problem is what happens when both systems update the same record at the same time. That is called a race condition, and we have seen it quietly break integrations, where one update truncates the other and you end up trusting data that is wrong.
With HubSpot and Business Central, the connection is trigger-based through Power Automate, the no-code automation tool in the Microsoft stack. There is a native connector that handles standard records like contacts, accounts, leads, and opportunities in a relatively light lift. Custom tables in HubSpot can require actual development. But trigger-based is exactly where the two-way sync risk shows up.
Decide who owns each record
The cleaner pattern is to assign ownership. One system owns and maintains a given piece of data, and pushes it to the other for visibility, not for editing. So you might say Business Central owns the customer and item records and pushes them out, while HubSpot owns the marketing and pipeline data. You still get one source of truth, and you avoid the tug-of-war.
One system owns the record. The other gets a copy to look at, not to fight over.
Point-to-point or middleware?
If you are only connecting two systems, a direct connection is often fine. But if you expect several platforms to talk to Business Central over time, a direct web of connections gets messy fast. That is when middleware earns its keep, sitting in the middle and sorting out the logic before signals reach your ERP.
| Approach | Good fit when | Trade-off |
|---|---|---|
| Point-to-point (Power Automate connector) | One or two systems, standard records | Gets tangled as you add more platforms |
| Middleware (Azure Service Bus) | Several systems feeding Business Central | More complex and more expensive to set up |
Azure Service Bus is the Microsoft middleware that handles those signals and lets you define what happens to each one. It is a more involved and more costly setup, so it is a trade-off, not an automatic yes. The right call depends on how many systems you plan to connect and how much logic needs to live between them.
If you are choosing a CRM partly to pull social, email, and pipeline into one place, that is a fair reason. Just map how it will sync with your ERP first, since the integration pattern affects your long-term maintenance more than the feature list does.
Get the architecture right early
The systems you pick matter less than how you wire them together. Deciding record ownership and choosing between direct connections and middleware up front saves you from rebuilding later. If you are connecting a CRM to Business Central and want to talk through which pattern fits your setup, we are glad to think it through with you.