It's Monday morning. Your sales team just submitted 15 quotes through Salesforce over the weekend. By Thursday afternoon, only 3 made it to your ERP for fulfillment. The other 12? Stuck somewhere in the integration process. Your team is manually checking each one. Your customers are waiting. And you're wondering why the "complete Salesforce-ERP integration" you paid €65,000 for isn't actually integrating anything.
This scenario isn't unusual. In the last six months, I've reviewed 14 Salesforce-ERP integrations for Swiss B2B companies. Eleven had the same fundamental problems. None of them were related to the technology itself.
The Problem Everyone Faces
Most Salesforce-ERP integrations work perfectly for 2-4 weeks. Then one of three things happens:
- Silent failures: Data stops syncing, but nobody notices until a customer calls about a missing order
- Cascading errors: One failed transaction blocks everything behind it, creating a backlog of 100+ failed syncs
- The vendor update: Your ERP provider pushes an update that changes a field name, and suddenly nothing works
The typical response? Call the integration vendor. Wait 48 hours. Pay for emergency support. Get a temporary patch. Repeat the cycle three months later.
Your operations team adapts by building "backup processes" — spreadsheets, manual checks, weekly reconciliation meetings. The integration becomes the problem it was supposed to solve.
Why This Happens (It's Not the Tools)
The issue isn't Salesforce. It's not your ERP. The middleware platform you chose is probably fine.
The problem is architecture — specifically, three assumptions that look reasonable during the sales process but break under real-world conditions:
Assumption 1: "Real-time sync is always better"
Real-time synchronization sounds ideal. Quote created in Salesforce? Instantly appears in ERP. Perfect, right?
Until your ERP is down for 15 minutes during a planned maintenance window. Or a network hiccup causes a timeout. Or someone saves an incomplete record. Real-time sync means real-time failures.
A Swiss manufacturer I worked with had real-time sync configured. When their ERP was briefly unavailable, 47 sales orders failed to sync. Because there was no queue, no retry mechanism, those orders simply... disappeared from the sync process. They discovered the problem four days later when customers started calling.
Assumption 2: "The integration handles everything automatically"
Most integrations are built for the happy path. Customer exists in both systems? Great. Standard product? No problem. Price list matches? Perfect.
But what happens when:
- A new customer exists in Salesforce but not yet in ERP?
- A special pricing agreement applies to this quote?
- The product is available but needs a custom configuration?
Without explicit error handling for edge cases, the integration silently fails or, worse, creates bad data. You discover the problem when accounting reconciles the month and finds discrepancies.
Assumption 3: "Once it works, it keeps working"
Integration projects have a testing phase. Everything passes. You go live. Success.
Then your ERP vendor updates to version 12.3. A field name changes. A data type shifts from string to integer. An API endpoint gets deprecated.
The integration breaks. And because nobody documented which fields, endpoints, or transformations the integration actually uses, fixing it takes days of investigation.
The Architecture That Actually Works
After seeing this pattern repeatedly, here's what prevents these failures:
Principle 1: Design for Failure
Assume failures will happen. Build for them explicitly:
- Use queues, not direct sync: When a record needs to sync, put it in a queue. Process the queue with retry logic. If something fails, it doesn't block everything else.
- Implement exponential backoff: First retry after 1 minute. Then 5 minutes. Then 15. This handles temporary issues without manual intervention.
- Alert on patterns, not individual failures: One failed sync? Normal. Ten failures in an hour? Alert someone.
A Swiss wholesale company implemented this approach. They still get occasional sync failures (customer not found, inventory temporarily locked, etc.), but these resolve automatically through retries. Manual intervention dropped from daily to once per month.
Principle 2: Make Failures Visible
The worst failures are silent. Design for visibility:
- Error dashboards: Show what failed, why, and what needs attention
- Weekly summary reports: "95% of syncs succeeded, 5% needed retry, 0.2% need manual review"
- Clear ownership: Someone needs to own integration health (usually operations, not IT)
You can't fix problems you don't know exist. Visibility is not optional.
Principle 3: Document Dependencies
When your integration breaks (and it will), you need to know:
- Which API endpoints it uses
- Which fields are mandatory vs optional
- What data transformations happen
- Which system is the source of truth for each data type
This documentation isn't for your current self. It's for your team six months from now when something breaks at 4 PM on Friday and you need to understand what changed.
Reality check: Good architecture won't prevent all failures. It makes failures manageable, visible, and fixable without emergency vendor support calls.
What This Looks Like in Practice
A Swiss B2B company with 120 employees came to me after their third "complete integration failure" in 18 months. Each time, they paid €5,000-€8,000 for emergency fixes.
We rebuilt their Salesforce-ERP integration with these principles:
- Queue-based processing (not real-time)
- Comprehensive error logging
- Daily automated health reports
- Clear documentation of every integration point
First month: 6 alerts that required attention (down from 15-20 manual interventions previously). Second month: 2 alerts. By month three: the integration just... worked.
Their ERP vendor pushed an update. The integration caught the affected records, logged clear errors, and the team fixed it in 2 hours instead of 2 days. No emergency support calls. No lost orders.
Questions to Ask Your Integration Vendor
Before your next integration project (or when evaluating your current one), ask:
- What happens when the ERP is temporarily unavailable? If the answer is "the sync will fail," ask about retry mechanisms.
- How do we know when something breaks? If the answer is "you'll see errors," ask for monitoring and alerting details.
- Who owns the documentation? If the answer is unclear or "we provide documentation," make sure you actually get usable documentation, not just API specs.
- What's the disaster recovery process? If something breaks at 6 PM on Friday, what happens? Is there a queue we can replay? Or do we lose data?
- Can our team modify this ourselves? Vendor lock-in isn't about the software. It's about knowledge lock-in.