Six Patterns Architects Use to Prevent Salesforce Integration Outages

Match the pattern to the workload, default to asynchronous and event-driven designs when volume or coupling risk is high, lock down identity with Named Credentials and scoped OAuth, and hand orchestration, retries, and transformation to middleware rather than Apex glue code. Platform Events, Change Data Capture, and Data Cloud handle most decoupled, high-volume scenarios, while Named Credentials and modern OAuth flows keep every connection auditable. Before your next integration kickoff, run a five-minute pattern check against the current design. It usually surfaces at least one place where a synchronous callout is quietly doing a job that an event should be doing.

TL;DR:

• Use event-driven patterns such as Platform Events or Change Data Capture for high-volume, decoupled scenarios to reduce synchronous callouts and improve scalability.
• Run a five-minute pattern check before implementation to identify synchronous callouts that should be replaced by event-based integrations, especially under high load.
• Default to asynchronous integration methods unless the user actively waits for immediate feedback, to prevent governor-limit issues and row locking errors.
• Prefer data virtualization via Salesforce Connect for changing, external data that doesn’t need to be stored inside Salesforce, or use data replication for data frequently needed in reports and flows.
• Implement comprehensive security practices, including storing credentials in Named Credentials, minimizing OAuth scopes, rotating tokens regularly, and restricting remote site settings to trusted domains.

Table of Contents

• What Are the Core Salesforce Integration Patterns?
• How Do You Choose the Right Integration Pattern?
• Should You Use Synchronous or Asynchronous Integration?
• Replication or Virtualization: Which Data Strategy Wins?
• What Security Controls Does Every Integration Need?
• How Do You Build Resilient, Observable Integrations?
• When Should You Use Middleware Instead of Native Salesforce Tools?
• What Should an Architect’s Integration Checklist Include?
• Our Take on Where Integration Projects Actually Go Wrong
• How Ampersand Labs Supports Salesforce Integration Projects
• Sources
• FAQ

What Are the Core Salesforce Integration Patterns?

Salesforce integration architecture breaks down into three categories: process, data, and virtual. Each solves a different problem, and picking the wrong one is the single most common cause of brittle integrations that fall over under load.

Process integration connects business processes across systems, usually to keep a workflow moving in near real time. Data integration copies or synchronizes records between systems so each has its own consistent copy. Virtual integration avoids copying data altogether, querying the source system on demand instead. Salesforce’s own architecture documentation lays out this three-way split and a selection matrix that maps each category to specific patterns, and it’s worth keeping open during any design session.

Within those three categories, six patterns cover almost everything you’ll build:

• Request and reply: a synchronous call where the caller blocks until it gets a response, typically over REST or SOAP. Best for user-facing lookups that need an answer in under a second, like a credit check during checkout. Failure mode: timeouts cascade back to the user if the downstream system is slow.
• Fire and forget: the caller sends a message and moves on without waiting for confirmation. Good for logging, notifications, or anything where the caller doesn’t need to know the outcome immediately. Failure mode: silent message loss if there’s no acknowledgment or retry layer.
• Batch data sync: large volumes move on a schedule, usually nightly, using Bulk API. Suited to data warehouse syncs or legacy system reconciliation where near real time isn’t required. Failure mode: partial batch failures that leave two systems out of sync until the next run.
• Remote call-in: an external system calls into Salesforce, often via REST API or Apex REST endpoints, to read or write records. Common for mobile apps or partner portals. Failure mode: governor limits get hit when external systems don’t respect Salesforce’s per-transaction ceilings.
• Data virtualization: Salesforce queries an external system’s data on demand instead of storing a copy, typically through Salesforce Connect and OData or custom adapters. Fits cases where data changes too often to keep replicated, or where storage cost and duplication are a concern. Failure mode: the entire experience degrades if the external system’s response time slips.
• Publish and subscribe: an event is broadcast once and any number of subscribers pick it up, using Platform Events, Change Data Capture, or the Pub/Sub API. This is the pattern for one-to-many notification scenarios, like alerting five downstream systems the moment an opportunity closes. Failure mode: subscribers falling behind the event retention window and missing messages permanently.

The Salesforce blog’s own guidance on aligning patterns to use cases makes a point worth repeating: event-driven approaches avoid blocking the caller and tend to handle concurrency far better than synchronous callouts once volume climbs. That’s the pattern most architects reach for too late, after a synchronous integration has already caused a production incident.

How Do You Choose the Right Integration Pattern?

Run every integration decision through six dimensions before writing a line of code: timing requirements, data ownership, data volume, transactional needs, failure semantics, and latency SLA. Skipping this step is how teams end up retrofitting an event bus onto something built as a synchronous callout six months earlier.

Timing asks whether the business process needs a result now or can tolerate a delay. A price quote needed at checkout is different from a monthly commission calculation. Data ownership asks which system is the source of truth. If Salesforce isn’t authoritative for the pricing catalog, don’t replicate it into Salesforce and hope it stays fresh. Data volume, sometimes labeled LDV (large data volumes), determines whether you need Bulk API and asynchronous jobs instead of anything transactional.

Transactional needs cover whether an operation must succeed or fail as a unit. Failure semantics ask what happens when a downstream system is unreachable. Does the record queue for retry, does the user see an error, or does the record get dropped? Latency SLA is the ceiling on acceptable response time, and it should come from the business, not from what’s convenient to build.

A few scenarios map cleanly:

• A field service technician checking real-time inventory before dispatch needs request and reply or, if volume is high, data virtualization through Salesforce Connect.
• An opportunity closing that should trigger a Slack notification, an ERP order, and a marketing automation flag fits publish and subscribe with Platform Events, since three separate systems need the same signal.
• A nightly product catalog refresh from an ERP system belongs in batch data sync using Bulk API, not a real-time callout on every save.
• A partner portal writing leads into Salesforce during business hours is a remote call-in candidate secured with a scoped connected app.

For workshop use, a short checklist keeps the conversation grounded: What is the latency SLA, in seconds or hours? Who owns the record after this transaction? What is the expected daily volume? What happens on failure, retry, alert, or drop? Does this need a guaranteed once-only delivery, or is duplicate handling acceptable downstream? Answer those five questions before touching the pattern catalog, and the right choice is usually obvious.

Should You Use Synchronous or Asynchronous Integration?

Default to asynchronous unless the user is actively waiting on a screen for the result. That single rule prevents most of the governor-limit and locking problems architects run into after go-live.

Synchronous integrations feel easier to build, which is exactly why teams default to them even when the business case doesn’t call for it. Salesforce’s own review of common architectural mistakes names over-reliance on synchronous callouts as a recurring failure pattern, usually because nobody checked the actual SLA before writing the integration. A synchronous call that blocks a Salesforce transaction while waiting on a slow external API risks hitting the CPU time limit, and if that external system also writes back to the same records, you get row-locking contention that manifests as random UNABLE_TO_LOCK_ROW errors under load.

The decoupling fix is almost always the same: move the write off the critical path. Publish a Platform Event instead of calling out directly, let a subscriber process it asynchronously, and give the user an immediate acknowledgment rather than a spinner. Change Data Capture works well when you need to react to record changes without writing trigger logic for every object, since it publishes change events automatically based on subscription. The Pub/Sub API is the newer, protocol-buffer-based channel that supports both publishing and subscribing at scale, and it’s the recommended path for high-throughput event streams going forward.

A few rules of thumb hold up across most projects:

• If the user is staring at a screen waiting for the result, synchronous is probably correct.
• If three or more systems need to know about the same event, publish and subscribe beats three separate point-to-point callouts.
• If volume can spike unpredictably, asynchronous with a queue absorbs the spike; synchronous just times out.
• If the external system’s uptime is worse than Salesforce’s, don’t let its downtime take Salesforce down with it.

Pro Tip: Watch your API call budget when publishing events through the REST API endpoint rather than natively through Apex or Flow. Community guidance notes that API-published events count against your daily API limit, while native publishing methods don’t, and that difference matters a lot once you’re publishing thousands of events a day.

Replication or Virtualization: Which Data Strategy Wins?

Copy data into Salesforce when it needs to be fast, queryable, and reportable inside the platform. Leave it external and query on demand when it changes too often to keep synchronized or when duplicating it creates a compliance headache.

Replication means storing a copy of external data as Salesforce records, refreshed on a schedule or via events. It’s the right call for anything users report on inside Salesforce or reference in flows and validation rules, since virtualized data can’t always support that natively. Virtualization, through Salesforce Connect and external objects, skips the copy and queries the source system live. It fits large catalogs that change constantly, like a distributor’s real-time pricing table, where keeping a synchronized copy would mean constant sync jobs fighting freshness against storage cost.

Zero-copy approaches extend this further. Salesforce’s guidance on Data 360 integration patterns describes ingestion modes that let Data Cloud reference data in place, rather than duplicating it across every connected system, which matters when a data warehouse and Salesforce both need the same customer record without becoming two sources of truth.

Master data ownership needs to be settled before any sync job gets written, not after. Decide up front which system is authoritative for each entity, customer, product, pricing, and document that as a schema contract both teams sign off on. Deduplication logic belongs at the point of ingestion, not as a cleanup job six months later when duplicate accounts have already polluted every downstream report.

A few practical guardrails:

• Treat the schema as a contract between systems; a field type change on either side should require sign-off, not just a deploy.
• Use Salesforce Connect for read-heavy, low-latency-tolerant external data rather than replicating it.
• Reach for Data Cloud when you need a unified customer profile across many source systems, not as a general-purpose ETL replacement.
• Bring in middleware when transformation logic between systems gets complex enough that Apex would turn into an unmaintainable mapping layer.

For large data volume loads, tune Bulk API batch sizes starting around 200 records and adjust based on downstream system concurrency limits, since pushing too hard against a partner’s ingestion rate just shifts the bottleneck without solving it.

What Security Controls Does Every Integration Need?

Store zero credentials in code, minimize every OAuth scope, and rotate tokens on a schedule, not just when something breaks. That’s the baseline, and integrations that skip it are the ones that show up in incident reports.

Named Credentials exist so you never hardcode an endpoint URL or an authentication token in Apex. They centralize the connection details and let Salesforce handle the OAuth handshake, which also means a credential rotation doesn’t require a code deployment. External Client Apps are the modern replacement for legacy connected app configuration, and Salesforce’s Spring '26 release pushed hard on migrating older setups over. Community-maintained security best-practice references are explicit that hardcoded secrets and overly broad OAuth scopes are the two most common findings in integration security reviews.

On OAuth specifically: minimize scopes to exactly what the integration needs, nothing broader. Use the JWT bearer flow for server-to-server integrations where no user is present to authenticate interactively. Use PKCE for any public client, like a mobile app, where a client secret can’t be safely stored. Rotate tokens on a defined schedule rather than leaving long-lived tokens active indefinitely.

A widely cited industry pattern: integrations that centralize credential storage through named connections rather than inline secrets see far fewer incidents tied to leaked or stale tokens, since rotation becomes a configuration change instead of a code deploy.

Beyond identity, a few network and compliance controls round out the checklist:

• Restrict remote site settings to the exact domains an integration needs, not a wildcard.
• Track certificate expiration dates centrally; a lapsed certificate silently breaking an integration overnight is one of the most common self-inflicted outages.
• Encrypt personally identifiable information both in transit and at rest wherever the integration touches it.
• Document data flows for GDPR or equivalent regimes, especially when personal data crosses a border between systems.

How Do You Build Resilient, Observable Integrations?

Assume every downstream call will eventually fail, and design the retry, alerting, and idempotency logic before the happy path, not after the first outage.

Retry strategy should use exponential backoff with jitter, not fixed-interval retries that all hit the failed system at the same moment and make an outage worse. A typical pattern: retry after 2 seconds, then 4, then 8, with a small random offset added to each, capping at a defined maximum before giving up. Circuit breakers stop calling a downstream system entirely once it’s shown a pattern of failures, giving it room to recover instead of getting hammered by retries from every integration that depends on it. Dead-letter queues catch anything that exhausts its retries, so failed messages get reviewed and reprocessed manually instead of vanishing.

Idempotency matters most in exactly the scenarios where retries happen: if a message gets processed twice because an acknowledgment was lost, the second processing shouldn’t create a duplicate record. Transaction IDs passed with every message, checked against a unique constraint on the receiving end, are the standard fix. Salesforce’s own event architecture supports this well: replayable events with replay IDs let a subscriber that missed messages catch back up from a known point rather than guessing what it lost.

Observability closes the loop. Centralized logging across every system in the integration chain, distributed tracing so a single transaction can be followed end to end, and dashboards tracking error rate, latency percentiles, and queue depth all belong in the design from day one, not bolted on after the first production incident.

A short operational list worth keeping visible:

• Retry with exponential backoff and jitter, capped at a sane maximum attempt count.
• Route exhausted retries to a dead-letter queue with an alert, not a silent drop.
• Attach a unique transaction ID to every message and enforce it as a uniqueness constraint downstream.
• Track error rate, p95 latency, and queue depth as standing metrics, not just uptime.

Pro Tip: Test your retry and dead-letter logic in a staging environment by deliberately taking a downstream mock offline mid-run. Most teams only discover their backoff logic is broken during a real outage, which is the worst possible time to find out.

When Should You Use Middleware Instead of Native Salesforce Tools?

Reach for middleware, an integration platform (iPaaS), enterprise service bus, or API gateway, the moment orchestration across more than two systems, protocol translation, or centralized policy enforcement enters the picture. Native Salesforce tools handle plenty on their own, but they were never meant to be an orchestration layer for a five-system workflow.

Middleware earns its place through a specific set of responsibilities: orchestration across multiple downstream calls in a defined sequence, protocol mediation when one system speaks SOAP and another speaks REST or a message queue protocol, throttling to protect systems with lower capacity than Salesforce, transformation of payloads between incompatible data models, and policy enforcement like rate limiting or authentication checks applied consistently across every integration rather than reimplemented in each one.

Native Salesforce integration, through Platform Events, Apex REST, or a direct connected app, works fine for simple, two-system point-to-point connections where none of that orchestration complexity exists. The moment a third system enters the picture, or transformation logic starts spanning multiple Apex classes just to reshape a payload, that’s the signal to move the logic into middleware instead of letting it sprawl inside the org.

Layering APIs by responsibility pays off as integration count grows. System APIs wrap a single backend system with a stable interface. Process APIs compose multiple system APIs into a business-level operation. Experience APIs shape data for a specific channel, mobile, web, partner portal. Documentation on API-first integration architecture frames this layering as the difference between integrations that get reused across projects and integrations that get rebuilt from scratch every time a new consumer shows up.

• Use middleware when three or more systems need coordinated orchestration for a single business process.
• Keep it native when the integration is a simple, low-volume, two-system connection.
• Layer APIs by System, Process, and Experience to maximize reuse across future projects.

What Should an Architect’s Integration Checklist Include?

A design review that skips ownership, rollback, and monitoring on day one is a design review that generates an incident later. A thorough checklist before implementation starts is worth adopting wholesale for integration engagements.

Design review items: document high-level requirements and the business SLA before picking a pattern. Write an architecture decision record for every non-trivial choice, sync versus async, replication versus virtualization, so the reasoning survives staff turnover. Assign clear ownership for each integrated system, including who gets paged when it breaks. Define a rollback plan before deployment, not during an incident.

CI/CD validation items: automate OAuth redirect URI tests so a configuration change doesn’t silently break authentication in production. Check certificate expiration dates as part of the pipeline, not as a manual calendar reminder, since Spring '26’s identity changes made certificate lifecycle management a first-class operational concern rather than a background task. Verify every external endpoint responds correctly as a deployment gate, catching a misconfigured Named Credential before it reaches users.

Monitoring runbooks: define what triggers an alert, who receives it, and what the first three troubleshooting steps are, written down before the integration goes live, not improvised during the first outage.

• Document an architecture decision record for every pattern choice made during design.
• Run automated OAuth and certificate checks as a deployment gate, not a manual step.
• Assign named ownership and an escalation path for every integrated system.
• Write the rollback plan before the first deployment, not after the first failure.

Our Take on Where Integration Projects Actually Go Wrong

Most integration failures encountered during audits trace back to decisions that felt reasonable at the time: building synchronously for speed, skipping architecture decision records due to tight deadlines, or hardcoding tokens instead of proper credential management for quick integrations. None of these are ignorance. They’re small, individually defensible shortcuts that compound.

The pattern catalog and the security checklist in this guide are practical checks used on integration engagements, from straightforward ERP syncs to multi-system event architectures. Early senior involvement in the architecture conversation, not only at handoff, helps catch premature synchronous callouts before deployment. A typical engagement runs audit, then plan, then implement, then ongoing support, and most of the real value shows up in that first audit step, where the gap between what a system was supposed to do and what it actually does becomes visible.

If you’re staring at a legacy integration that nobody fully trusts anymore, or a new project where the pattern choice still feels uncertain, that’s the right moment to bring in an outside architecture review before more code gets written on top of an unclear foundation.

, Davide Morotti

How Ampersand Labs Supports Salesforce Integration Projects

Building the right integration architecture the first time costs less than untangling a synchronous, hardcoded one after it’s live and load-bearing. Salesforce integration and API development engagements benefit from senior architects being involved from the first workshop rather than only after contract signing, which helps catch pattern-selection mistakes early instead of in production.

A typical engagement may include an audit of the current integration landscape, proof-of-concept for risky pattern decisions, implementation, and ongoing support to keep the architecture maintainable as new systems are added. Services may include system integrations, API development, interim CTO support, CI/CD and security audits, and AI automation for workflows adjacent to Salesforce data.

If a current integration feels fragile, or you’re about to design one and want a second set of senior eyes on the pattern choice before code gets written, start with the System Integration & API Development page to see how an audit and implementation engagement is scoped.

Sources

• Integration Patterns | Data 360 and Integration
• Align integration patterns to use cases
• Security best practices for integrations (community reference)
• Salesforce Spring ’26: designing a resilient enterprise integration architecture

FAQ

What Are the Best Salesforce Integration Tools?

Platform Events, Change Data Capture, and the Pub/Sub API cover most event-driven scenarios, while Named Credentials and Salesforce Connect handle secure connections and data virtualization. For orchestration across more than two systems, an integration platform (iPaaS) or API gateway generally outperforms native tools alone.

What Are Some Best Practices for Salesforce Development in Integration Projects?

Design against a pattern selection framework before writing code, default to asynchronous methods for anything beyond simple two-system connections, and secure every credential through Named Credentials rather than hardcoding tokens. Build idempotency and retry logic in from the start rather than adding it after the first production failure.

How Do You Integrate Salesforce With Another Salesforce Org?

Org-to-org integration typically uses Platform Events or Change Data Capture for near real-time sync, or the Bulk API for scheduled batch transfers of larger data volumes. Named Credentials on both orgs, paired with a connected app or External Client App using OAuth, keep the connection secure without hardcoded secrets.

What’s the Difference Between Change Data Capture and Platform Events?

Change Data Capture automatically publishes change events whenever a subscribed object’s records are created, updated, deleted, or undeleted, with no custom trigger logic required. Platform Events are custom-defined events you publish explicitly from Apex, Flow, or an external system for any business event, not just record changes.

When Should You Use Salesforce Connect Instead of Data Replication?

Use Salesforce Connect when external data changes too frequently to keep a synchronized copy fresh, or when duplicating that data creates storage or compliance concerns. Choose replication instead when users need to report on the data inside Salesforce or reference it in flows and validation rules that virtualized objects can’t fully support.

Recommended

• System Integration & API Development Zürich
• AI Automation & Workflow Agents Zürich