Most Salesforce implementations fail at the integration layer, not the CRM configuration. The platform itself is robust. The data model is well-documented. The APIs work. But the way teams connect Salesforce to the rest of their stack often creates invisible liabilities that compound over years.
The three integration anti-patterns
1. The infinite polling loop
A scheduled job that queries Salesforce every five minutes for "changed records." Works fine at launch. Breaks silently when data volume grows. By the time anyone notices, you're missing critical updates and the API governor limits are already being hit.
Better approach: Platform Events or Change Data Capture. Push instead of pull. Event-driven instead of polling.
2. The direct database dependency
Your ERP, warehouse, and marketing tools all read from the same Salesforce objects directly. No abstraction layer. No transformation logic. When the Salesforce admin renames a field or adds validation rules, three downstream systems break.
Better approach: A thin API layer that owns the Salesforce boundary. Transform at the edge. Decouple the internal Salesforce model from external consumers.
3. The mega-sync batch job
A nightly job that extracts everything, transforms everything, and loads everything. 4-hour window. Complex retry logic. Zero incremental capability. When it fails at 3am, your team wakes up to stale data and a 400-page error log.
Better approach: Incremental, idempotent, event-based sync. Small batches. Clear ownership of each data domain.
What works at scale
Domain-driven boundaries. Don't sync "Salesforce data." Sync CustomerProfile, OpportunityStatus, SupportTicket. Each domain owns its transformation logic and publication schedule.
Asynchronous by default. Synchronous Salesforce calls should be the exception, not the rule. Queue it. Acknowledge quickly. Process reliably.
Observability at the integration layer. Log API call volumes, response times, and error rates. Alert on anomalies before they become incidents.
Graceful degradation. If Salesforce is slow or unavailable, your other systems should continue functioning with stale-but-reasonable data. Never let a CRM outage take down your checkout flow.
The integration decision framework
| Factor | Synchronous API | Platform Events | Batch ETL | |--------|-----------------|-------------------|-----------| | Real-time requirement | Yes | Yes | No | | Data volume | Low | High | Very high | | Complexity | Simple | Medium | Complex | | Failure impact | Immediate | Recoverable | Delayed |
Choose the pattern that matches your actual requirements, not the one that's easiest to implement this week.
The Fulcra approach
We typically see these patterns in the wild:
- Real-time customer sync: Platform Events → Kafka → downstream services. Sub-second propagation for critical profile updates.
- Nightly financial reconciliation: Incremental batch with watermark tracking. Idempotent writes. Clear audit trail.
- Quote-to-cash flow: Event-driven from CPQ through ERP. Each system owns its domain. Asynchronous handoffs with state machine tracking.
The architecture depends on your transaction volumes, your compliance requirements, and your tolerance for eventual consistency. But the principle is consistent: treat Salesforce as one node in a distributed system, not the center of your data universe.
If you're planning a Salesforce integration or dealing with the consequences of an existing one, we can help assess the architecture.