Some problems are unique to specific industries, specific ERPs, or specific company sizes. And then there are the mistakes that show up on nearly every ERP–CRM integration project we've worked on, regardless of which systems are involved.
These aren't obscure edge cases. They're predictable, avoidable, and expensive when they happen late in a project. Here they are — with what to do instead.
Syncing Everything Instead of What Matters
The instinct on every integration project is to sync as much as possible. More data means more visibility, right? In practice, syncing every ERP object and every field produces a cluttered Salesforce org where sales reps can't find what they need, page loads are slow from the data volume, and storage costs climb for no good reason.
The data that matters for Salesforce users is usually a small subset of what the ERP contains: customer account status, recent invoice history, outstanding balance, current pricing. Everything else is noise that gets in the way.
Before designing the integration, spend an hour with the actual Salesforce users — sales reps, account managers, ops staff — and ask them: what ERP data do you wish you had in Salesforce today? Build the integration around those answers. You can always add more later.
No Data Ownership Model
When a customer's address changes, which system should it be changed in? When a new customer is created, does it start in the ERP or in Salesforce? If a rep updates a phone number in Salesforce and the ERP overwrites it on the next sync, whose version wins?
These questions seem minor before the integration is built. After go-live, they cause real problems — data that gets corrected in one system and immediately overwritten by the other, users who stop trusting either system, and a support queue full of "why did my change disappear" tickets.
Document data ownership for every entity the integration touches before you build anything. Each field or object should have one master system. Write it down, get sign-off from both IT and the business, and encode it in the integration logic so the sync respects ownership boundaries.
Building Bidirectional Sync When You Don't Need It
Bidirectional integration — where both systems can write to the same data and changes flow in both directions — sounds like the ideal end state. It's also significantly more complex to build, more expensive to maintain, and a reliable source of conflicts and sync loops when something goes wrong.
The majority of ERP–Salesforce integrations we see don't actually need full bidirectionality. Sales reps need to read ERP data in Salesforce — they don't need to write back to the ERP. Customer data is mastered in the ERP — it doesn't need to be editable in Salesforce. Pricing flows from ERP to Salesforce — not the other way.
Default to unidirectional sync and only add write-back where there's a genuine business requirement for it. "It would be nice if" is not a business requirement. "Our sales process requires reps to create orders in Salesforce that feed directly to the ERP" is. Be rigorous about the distinction.
Ignoring the Historical Data Question
The integration goes live. Data starts flowing for the current period. A sales rep opens a customer record and sees their invoice history — going back three weeks, to when the integration was turned on. Five years of relationship history is sitting in the ERP and none of it is visible in Salesforce.
This is almost always a surprise to the business. It's rarely discussed during scoping, and by go-live it's too late to do it cleanly — loading historical data after the sync is running creates edge cases and potential conflicts that are harder to manage than loading it before go-live.
Decide on the historical data strategy during the design phase, not during UAT. Options are: no history (accept the limitation), load history before go-live (ideal), or load history as a separate post-go-live project (acceptable but more complex). The answer depends on how much history matters for your users' day-to-day work.
No Plan for When It Breaks
Every integration breaks eventually. A record fails to sync because a required field is blank. An API timeout causes a batch to partially complete. An ERP upgrade changes a field name that the integration was reading. These aren't signs of a bad integration — they're normal operational events for any system that moves data between two platforms.
The problem is when nobody has a plan for handling them. Errors pile up unnoticed. Users start seeing stale data and lose trust. By the time someone investigates, there are hundreds of failed records to sort through and no clear owner for the cleanup.
Before go-live, define: how are sync errors logged, who reviews them and how often, what does the escalation path look like, and who is responsible for the integration health ongoing? A weekly review of the error log by a designated owner will catch most problems before they compound. The operational model matters as much as the technical implementation.
The Pattern Underneath All Five
Look at the five mistakes above and the pattern is clear: they're all things that get decided (or not decided) before the technical work starts. Scope, data ownership, sync direction, historical data, and operational ownership are all design and governance questions, not engineering questions.
The engineering on an ERP–Salesforce integration is rarely the hard part. The hard part is getting the business and IT aligned on the right answers to the right questions before anyone writes a line of code. The projects that do this well tend to go smoothly. The ones that don't tend to end up in our inboxes six months later asking how to fix a problem that should have been solved in week one.
If you're about to start an integration project and want a structured way to answer these questions before the build begins, we offer a half-day discovery engagement specifically for this. Reach out and we'll explain what it involves.