Salesforce Integration Architecture: Patterns That Actually Scale

The integration pattern you choose, not the tool, decides whether Salesforce data stays clean or turns into a synchronization mess. Point-to-point connections are fast to build and fast to break; middleware and event-driven patterns cost more upfront but survive the third, fourth, and tenth system you connect. Most integration pain traces back to that early architecture decision, not to Salesforce itself.

Why do most Salesforce integrations break down?

Two systems rarely share the same data model. Salesforce thinks in Accounts, Contacts, and Opportunities; an ERP thinks in customer master records and sales orders. Every integration has to reconcile those shapes, and teams that skip this step end up bolting fields onto Salesforce objects to mirror whatever the other system sends. Six months later nobody remembers why Custom_ERP_ID__c exists or what happens if it's blank.

The fix isn't a tool, it's a canonical data model: decide what an "Account" means across your systems before you write a single integration flow, and build transformation logic around that definition instead of letting the last-connected system dictate the schema.

Point-to-point or middleware: which pattern fits?

Point-to-point integrations, a direct API call from Salesforce to System B, make sense for one or two connections with simple, stable data. Once you're integrating three or more systems, point-to-point becomes an unmaintainable web: every new connection multiplies the number of places a field mapping can drift out of sync.

A middleware or ESB layer, such as MuleSoft, Boomi, or a lighter custom message broker, centralizes transformation and routing so Salesforce talks to one integration layer instead of five downstream systems directly. That's a real infrastructure investment, so it's worth reserving for integration landscapes that are actually growing, not a single one-off sync.

How do you handle real-time vs batch data?

Not everything needs to sync instantly, and treating every integration as real-time is how teams burn through Salesforce API limits for no benefit. A useful rule of thumb:

• Use Platform Events or Change Data Capture for anything a user needs to see reflected immediately, like order status or support case updates.
• Use scheduled batch jobs and the Bulk API for large, non-urgent volumes, like nightly financial reconciliation.
• Avoid polling loops that hit the REST API on a timer just because it's easier to build. They waste API calls and add latency compared to event-driven alternatives.

Change Data Capture is underused: it publishes field-level change events for standard and custom objects without you having to build custom triggers to detect what changed.

How do you prevent duplicate records and failed syncs?

Every integration eventually retries a request, whether from a timeout or a queued job that runs twice. If your integration isn't idempotent, that retry creates a duplicate Opportunity or double-counts a metric. The fix is a stable external ID field on the Salesforce object, paired with upsert calls keyed to that ID instead of blind create calls.

Error handling deserves the same rigor as the happy path. Failed records should land in a dead-letter queue or error log with enough context to reprocess them, not silently vanish because a single record in a 200-record batch failed validation.

MuleSoft or a custom-built integration layer?

MuleSoft earns its cost with many systems, a dedicated integration team, and connectors that map closely to what you're building. A custom-built layer using Apex, a message queue, and a lightweight orchestration service is often cheaper to ship for a handful of well-defined integrations through dedicated development work, but it puts long-term maintenance on your own engineering team.

It's a build-versus-buy tradeoff that depends on integration count and how fast your system landscape is growing. That decision is worth getting outside eyes on before you commit, which is where Tekunda's integration services come in: we help teams pick and implement the pattern that fits their actual roadmap, not the one a vendor demo made look easy.

FAQ

What's the difference between Platform Events and Change Data Capture?

Platform Events are custom-defined messages you publish explicitly from Apex or a flow, while Change Data Capture automatically emits events when standard or custom object records change, with no custom publishing logic required.

Do I need MuleSoft to integrate Salesforce with other systems?

No. MuleSoft is one option among several, including Boomi, Informatica, or a custom-built middleware layer; the right choice depends on how many systems you're connecting and who will maintain the integration long-term.

How do I avoid hitting Salesforce API limits?

Batch large data volumes through the Bulk API instead of single-record REST calls, use Platform Events or Change Data Capture instead of polling, and combine related calls where the API supports composite requests.

What's the safest way to authenticate a third-party integration with Salesforce?

Use a Connected App with OAuth 2.0, scope the permissions to only what the integration needs, and rotate credentials on a schedule rather than relying on a single long-lived token.