Executive Summary

Salesforce integrations should be designed from the outside in: start with business timing, user experience, data ownership, failure tolerance, compliance constraints, and expected scale, then choose the narrowest technology that solves that exact problem. Salesforce’s own architecture guidance is explicit on several high-level principles: avoid unnecessary data replication when virtualization is sufficient, favor enterprise ESB/ETL tooling when it already exists in the landscape, use event-driven patterns for asynchronous decoupling, prefer Platform Events and Change Data Capture for record-change notifications, and use Pub/Sub API rather than starting new Streaming API–based pub/sub implementations.

For advanced practitioners, the hardest part is rarely “how do I call an API?” It is deciding which integration contract is authoritative, how to preserve security semantics across systems, how to keep writes idempotent, how to recover from partial failure, and how to observe a transaction as it crosses sync and async boundaries. Salesforce provides multiple overlapping tools because different integration problems have materially different shapes: REST and SOAP APIs for transactional CRUD and service operations, Bulk API 2.0 for large-scale asynchronous data movement, Platform Events and CDC for eventing, Salesforce Connect for virtualization, External Services and Named Credentials for governed outbound calls, MuleSoft for orchestration and API-led connectivity, and Heroku Connect when Salesforce and Heroku Postgres must stay synchronized.

The most important architectural trade-off is coupling. Request/response patterns maximize immediacy but also maximize temporal coupling and expose users directly to downstream latency and failure. Fire-and-forget, batch, and event-driven patterns trade immediacy for resilience, scalability, and independent evolution. Middleware and API-led connectivity shift complexity into a reusable control plane, which increases up-front design effort but usually lowers long-term total cost of ownership in large enterprises. Salesforce’s decision guides repeatedly emphasize maintainability, transformation needs, data volume, and existing landscape as first-order selection criteria.

Identity and security choices are just as architectural as transport choices. OAuth remains the primary authorization model, but flow selection matters: authorization code and refresh token for delegated user access; client credentials or JWT for server-to-server; SAML when federation or SP/IdP patterns are required. Connected Apps still matter, especially where SAML is involved, but Salesforce now increasingly recommends External Client Apps for new integrations, and official docs note that creation of new Connected Apps became restricted as of Spring ’26 while existing Connected Apps continue to work. Named Credentials and External Credentials should be the default outbound auth abstraction because they centralize endpoint/auth settings and encrypt stored credential material.

A few details are unspecified in the request and materially affect the “best” design: Salesforce edition and add-ons, expected daily API/event volumes, whether data must remain outside Salesforce, whether regulated data is in scope, whether MuleSoft/Heroku/Data 360 are already licensed, and whether user-facing interactions can tolerate eventual consistency. Accordingly, the cost and tool recommendations below are qualitative and architecture-oriented rather than contract-pricing advice. Exact entitlements for high-volume events, Event Monitoring, Salesforce Connect, Data 360, Heroku Connect, and Shield-related features depend on edition and purchased licenses.

Pattern Landscape and Decision Framework

Salesforce’s integration-pattern guidance treats patterns as reusable responses to recurring enterprise scenarios rather than as product-specific recipes. That framing matters: the right first question is not “REST or Platform Events?” but “does a human wait for the answer, or can the business process continue asynchronously?” Salesforce’s event-driven decision guide states plainly that event-driven architecture is a poor fit when a human must wait for an immediate response, and that it is most effective for near-real-time notifications, load distribution, and resilient cross-system processing.

A practical decision model for advanced architects is shown below.

flowchart TD
    A[Business process starts] --> B{Must the user wait?}
    B -->|Yes| C[Request/Response]
    B -->|No| D{Need continuous, near-real-time propagation?}
    D -->|Yes| E[Event-Driven or Pub/Sub]
    D -->|No| F{Large volume or scheduled movement?}
    F -->|Yes| G[Batch or ETL/ELT]
    F -->|No| H{Need data visible in Salesforce without replication?}
    H -->|Yes| I[Virtualization with Salesforce Connect]
    H -->|No| J{Need orchestration across many systems?}
    J -->|Yes| K[Middleware or API-Led Connectivity]
    J -->|No| L[Simple Fire-and-Forget or direct API]

This diagram synthesizes Salesforce Integration Patterns guidance, the Data Integration Decision Guide, and MuleSoft’s API-led and orchestration documentation.

Pattern selection matrix

The most common architectural mistake is using request/response everywhere because it is easiest to prototype. That usually produces brittle point-to-point coupling, poor failure isolation, and low reuse. A second common mistake is overusing replication. Salesforce’s data-integration guide explicitly recommends avoiding replication unless data truly needs to reside in Salesforce, and recommends Salesforce Connect when virtualization is sufficient.

API-led connectivity in Salesforce programs

API-led connectivity is MuleSoft’s pattern for decomposing integrations into reusable layers that “unlock data,” “compose processes,” and “deliver experiences.” In practice, advanced Salesforce programs normally map these to system APIs for ERP/MDM/platforms, process APIs for cross-system business orchestration, and experience APIs for channels such as Experience Cloud, mobile, or agent-facing consumers. Mule runtime documentation frames Mule applications as providing routing, mapping, orchestration, reliability, security, and scalability using API-led connectivity instead of point-to-point integrations.

flowchart LR
    subgraph Experience Layer
      X1[Experience API]
      X2[Agent or App Consumer]
    end
    subgraph Process Layer
      P1[Order Orchestration API]
      P2[Customer Sync API]
    end
    subgraph System Layer
      S1[Salesforce System API]
      S2[ERP System API]
      S3[Identity or MDM API]
    end

    X2 --> X1 --> P1
    X1 --> P2
    P1 --> S1
    P1 --> S2
    P2 --> S1
    P2 --> S3

Use this pattern when more than one consuming channel needs the same business capability, when governance is important, or when your team wants to stop rebuilding the same transformations and auth policies in multiple point integrations.

Salesforce Integration Technologies

Salesforce does not have a single “best” integration technology. Its own decision guide presents a portfolio and recommends selecting based on timing, data direction, scale, transformation needs, debugging/deployment requirements, and licensing.

Comparative option table

How to choose among overlapping options

Use REST API when the integration is transactional and the client can own the orchestration. Use Composite/Composite Graph when you need to reduce chattiness or perform related REST operations in one logical round trip. Use SOAP when your enterprise standards or existing client stack are WSDL-first and strongly typed. Use Bulk API 2.0 when data movement is large enough that synchronous APIs become operationally fragile or slow. Salesforce’s docs position Bulk API 2.0 as the REST-based async interface for large ingest and query operations, including large result sets for bulk query jobs.

Use Platform Events when you need a custom business event contract, and CDC when the external consumer primarily wants canonical record deltas from Salesforce. Salesforce’s event-driven guide explicitly recommends Platform Events and CDC as the preferred mechanisms for record and field changes, and recommends Pub/Sub API for future pub/sub work instead of building on older Streaming API patterns.

Use Salesforce Connect when the user experience requires external data in Salesforce but replication would add cost, storage, technical debt, or compliance risk. Use MuleSoft when the real need is not “an integration” but an enterprise integration operating model: reusable APIs, policy enforcement, transformation, orchestration, and centralized observability. Use Heroku Connect only when Heroku Postgres is intentionally part of the system-of-record story or application platform; it is not a general-purpose ERP connector.

Code and configuration examples

Apex callout with Named Credential and Queueable

public with sharing class ErpOrderPublisher implements Queueable, Database.AllowsCallouts {
    private final Id opportunityId;
    private final String correlationId;
    public ErpOrderPublisher(Id opportunityId, String correlationId) {
        this.opportunityId = opportunityId;
        this.correlationId = correlationId;
    }
    public void execute(QueueableContext qc) {
        Opportunity opp = [
            SELECT Id, Name, StageName, Account.External_ERP_Id__c,
                   Amount, CloseDate
            FROM Opportunity
            WHERE Id = :opportunityId
            LIMIT 1
        ];
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:ERP_Order_API/orders');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setHeader('X-Correlation-Id', correlationId);
        req.setTimeout(20000);
        Map<String, Object> body = new Map<String, Object>{
            'salesforceOpportunityId' => opp.Id,
            'erpAccountId'            => opp.Account.External_ERP_Id__c,
            'amount'                  => opp.Amount,
            'closeDate'               => String.valueOf(opp.CloseDate)
        };
        req.setBody(JSON.serialize(body));
        Http http = new Http();
        HttpResponse res = http.send(req);
        if (res.getStatusCode() >= 300) {
            System.debug(LoggingLevel.ERROR,
                'ERP publish failed: ' + res.getStatusCode() + ' ' + res.getBody());
            // Persist for retry / dead-letter handling
            insert new Integration_Error__c(
                Correlation_Id__c = correlationId,
                Source_Record_Id__c = opp.Id,
                Endpoint__c = 'ERP_Order_API/orders',
                Status_Code__c = String.valueOf(res.getStatusCode()),
                Response_Body__c = res.getBody()
            );
        }
    }
}

This pattern uses Queueable because Salesforce’s own decision guide advises asynchronous Apex for post-DML callouts from trigger-driven flows, and Queueable provides an observable async job boundary. Named Credentials are the recommended endpoint/auth abstraction because they centralize URL and authentication parameters; Apex transactions can make up to 100 callouts, and cumulative callout timeout is bounded, so bulkification and async isolation matter.

REST upsert using an External ID

curl --request PATCH \
  --url "https://yourInstance.salesforce.com/services/data/v65.0/sobjects/Account/External_ERP_Id__c/ERP-100245" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --header "X-SFDC-REQUEST-ID: 3c7f7a44-99d6-4b0a-a7b0-5c1e8a7b0a11" \
  --data '{
    "Name": "Acme Industrial",
    "BillingCity": "Pune",
    "BillingCountry": "IN"
  }'

Using external IDs for upsert is a foundational idempotency strategy in Salesforce. Salesforce supports upsert by external ID in REST, SOAP, Apex, and Bulk APIs, and UI API also supports idempotent record writes to reduce duplicates caused by network retries or client uncertainty. Correlation IDs can be propagated with X-SFDC-REQUEST-ID for cross-system tracing.

Bulk API 2.0 ingest sequence

# Create ingest job
curl --request POST \
  --url "https://yourInstance.salesforce.com/services/data/v65.0/jobs/ingest" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "object": "Contact",
    "operation": "upsert",
    "externalIdFieldName": "External_ERP_Id__c",
    "contentType": "CSV",
    "lineEnding": "LF"
  }'
# Upload CSV payload
curl --request PUT \
  --url "https://yourInstance.salesforce.com/services/data/v65.0/jobs/ingest/750xx0000000001AAA/batches" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Content-Type: text/csv" \
  --data-binary @contacts.csv
# Close the job
curl --request PATCH \
  --url "https://yourInstance.salesforce.com/services/data/v65.0/jobs/ingest/750xx0000000001AAA" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{"state":"UploadComplete"}'

This is the standard Bulk API 2.0 pattern: create job, upload data, close job, then poll for completion and retrieve success/failure results. Salesforce documents Bulk API 2.0 as the async interface for large ingest and query operations, and notes that Bulk Query is designed for large result sets; Bulk API and Bulk API 2.0 share certain daily allocations.

Mule flow with transformation and retry

<flow name="erp-contact-to-salesforce">
    <http:listener config-ref="httpListener" path="/erp/contact"/>
    <ee:transform doc:name="Normalize Contact">
        <ee:message>
            <ee:set-payload><![CDATA[
%dw 2.0
output application/java
---
{
  LastName: payload.lastName,
  FirstName: payload.firstName default null,
  Email: payload.email,
  External_ERP_Id__c: payload.erpContactId,
  Account: if (payload.erpAccountId != null)
             { External_ERP_Id__c: payload.erpAccountId }
           else null
}]]></ee:set-payload>
        </ee:message>
    </ee:transform>
    <until-successful maxRetries="3" millisBetweenRetries="5000">
        <salesforce:upsert config-ref="sfConfig"
                           type="Contact"
                           externalIdFieldName="External_ERP_Id__c"/>
    </until-successful>
    <error-handler>
        <on-error-propagate type="ANY">
            <logger level="ERROR" message='#[error.description]' />
        </on-error-propagate>
    </error-handler>
</flow>

This flow demonstrates three patterns MuleSoft documents directly: DataWeave as the transformation layer, orchestration via flows, and reliability using until-successful plus structured error handling. In larger programs, this flow would typically sit behind a system or process API rather than being called ad hoc from channels.

SOQL for monitoring event usage and logs

SELECT EventName, UsageType, Client, TimeSegment, Value
FROM PlatformEventUsageMetric
WHERE StartDate >= 2026-07-01T00:00:00Z
AND EndDate   <= 2026-07-03T23:59:59Z
ORDER BY StartDate DESC

SELECT Id, EventType, LogDate, LogFileLength, RequestId
FROM EventLogFile
WHERE EventType IN ('API', 'ApexExecution')
AND Interval = 'Hourly'
ORDER BY LogDate DESC

Salesforce provides PlatformEventUsageMetric for platform event and CDC usage visibility and EventLogFile for event monitoring logs; EventLogFile can also be correlated by request ID to understand a unit of work across API and Apex activity.

Identity, Security, and Data Contracts

Authentication and authorization are not interchangeable in Salesforce integration design. Connected Apps and External Client Apps define the trust boundary for inbound clients; OAuth scopes, policies, and token flows determine how access is granted; integration users, permission sets, sharing, and field-level security determine what that token can actually do. Salesforce’s decision guide explicitly recommends a dedicated integration user with API-only posture, and increasingly recommends External Client Applications in preference to older connected-app or SOAP-login patterns for integrations.

OAuth, JWT, SAML, Connected Apps, and External Client Apps

A Connected App is Salesforce’s classic framework for integrating external applications via OAuth, SAML, and OpenID Connect. It remains relevant, especially where SAML-based federation is required. However, Salesforce documentation now recommends External Client Apps for new API integrations in many scenarios, and official guidance notes that creation of new Connected Apps became restricted in Spring ’26 while existing Connected Apps continue to function. If you must support SAML service-provider or identity-provider configurations, Connected Apps are still directly relevant because they support SAML enablement and admin-controlled policies.

Use the authorization-code style flow when a human user is present and delegated access is intended. Use refresh tokens when sessions must be renewed without forcing re-consent. Use JWT bearer flow for headless server-to-server scenarios where certificate-based exchange is operationally preferable. Use client credentials when the app itself, rather than a user, should authenticate to Salesforce as a pre-approved integration principal. Use SAML when enterprise federation and browser-based SSO semantics are the primary requirement.

Named Credentials and External Credentials

For outbound integrations, do not hardcode hosts, secrets, or OAuth logic inside Apex unless there is no supported abstraction. Named Credentials define the endpoint; External Credentials define how Salesforce authenticates to the external service; the credential material is encrypted. Salesforce also supports named-principal and per-user identity models, which is critical for deciding whether an integration executes under a shared service identity or preserves end-user identity to the downstream system.

A robust rule of thumb is simple: if the downstream authorization model should reflect the acting user, prefer per-user principal. If the downstream system is an enterprise back end that should only trust a technical service account, use named principal. This is an architectural decision, not just a setup choice, because it affects auditability, data minimization, and least privilege.

Data modeling, mapping, and canonical contracts

Advanced integration design fails early when no one defines the canonical model. In Salesforce, that usually means deciding which fields are source-of-truth fields, which are derived, which are external IDs, and which contract version a consumer depends on. MuleSoft’s Cloud Information Model exists precisely to reduce cross-product coupling by giving System and Process APIs a common application-agnostic model. Within Salesforce, external IDs are especially important because they enable stable joins, efficient upserts, and idempotent write semantics across APIs.

When the external system owns the data and Salesforce only needs read-time access, Salesforce Connect is often cleaner than replication. External Objects behave similarly to custom objects but store their data outside Salesforce, usually through OData or a custom Apex adapter. By default, external objects are read-only, and Salesforce Connect is a license-provisioned capability. That means your data model must explicitly account for query patterns, search/user expectations, and source-system SLA.

Security and compliance by contract

Salesforce’s security model layers object, field, and record access, and Apex can enforce sharing and CRUD/FLS semantics through with sharing, security-aware APIs, and explicit checks. Secure integration design must respect those semantics instead of bypassing them under the guise of “system integration.” For sensitive data, Salesforce recommends classification-driven controls such as field-level security, encryption, and data masking. Shield Platform Encryption protects data at rest; Data Mask obfuscates sensitive production data when copied into sandboxes; and Health Check evaluates org security settings against Salesforce or custom baselines.

For AI integrations, this becomes even more important. Salesforce’s AI/Agentforce and Well-Architected materials describe the Einstein Trust Layer as a control plane for safeguarding data privacy and masking sensitive information before prompts are sent to LLMs. If AI interactions are part of an integration landscape, masking, classification, and outbound action governance must be treated as part of the integration architecture, not a separate “AI feature.”

Reliability, Transactions, and Scalability

The central reliability problem in Salesforce integration design is the mismatch between local transaction guarantees and distributed-system reality. Salesforce can guarantee transactional behavior inside its own unit of work, but once an external callout, event delivery, or downstream write is involved, you are in distributed-systems territory. That means retries, deduplication, compensation, and observability become mandatory design capabilities, not optional hardening tasks.

Error handling and retry strategy

Synchronous request/response integrations should return a business-grade error contract, not raw stack traces. Asynchronous integrations should separate transient failures from permanent failures. MuleSoft provides formal retry and reliability constructs such as reconnection strategies, until-successful, and typed error handling through on-error-* scopes. Salesforce-native async patterns often require a custom retry ledger, dead-letter object, or republish mechanism.

Outbound Messages are a special case: Salesforce documents them as SOAP-over-HTTP(S) notifications with guaranteed receipt behavior, retry semantics, and a queue that retains messages until successful delivery or until they age out after 24 hours. That makes them useful for certain low-code legacy integrations, but Salesforce’s current architecture guidance also says not to build new long-term strategies around them because no further major investment is planned.

A good retry model is shown below.

sequenceDiagram
    participant SF as Salesforce
    participant BUS as Event Bus or Middleware
    participant ERP as ERP

    SF->>BUS: Publish event or send request
    BUS->>ERP: Deliver message
    ERP-->>BUS: 503 / transient failure
    BUS-->>BUS: Retry with backoff
    BUS->>ERP: Retry attempt
    ERP-->>BUS: 200 OK
    BUS-->>SF: Update status / ack / metrics

This is the correct pattern for transient failure. For permanent business-rule failure, route to exception handling, operator review, or compensation rather than blind retry. That recommendation is implied across Salesforce reliability guidance and Mule reliability patterns.

Idempotency and duplicate prevention

Idempotency is non-negotiable for any integration that can be retried. Salesforce provides strong primitives for this: external IDs with upsert across REST, SOAP, Apex, and Bulk APIs; UI API idempotent record writes; and business-specific keys carried in events or callouts. Salesforce’s engineering guidance on idempotency also emphasizes that outbound messages and Apex callouts should carry enough state or remote identity to detect duplicates safely.

Practical patterns include using a source-system business key as an External ID, persisting a processed-message table keyed by event UUID or correlation ID, and designing event payloads so consumers can treat repeats as no-ops. For Platform Events, Salesforce also added publish callbacks and usage metrics that make it easier to reason about publish outcomes and operational consumption.

Transaction management and compensating actions

Inside Salesforce, transaction control is explicit: savepoints and rollback can protect local work, and Apex documentation calls out specifics such as releasing savepoints before certain callout patterns. Mule can demarcate transactional units, including XA transactions, for resources that support it. But neither of these facts means you should attempt a naïve distributed transaction across Salesforce, ERP, and middleware. In enterprise practice, compensation or saga-style recovery is the safer pattern: commit each local step, emit status, and compensate when a later step fails. That final recommendation is an architectural inference grounded in documented transaction boundaries rather than an explicit product promise.

Performance, limits, concurrency, and bulkification

Salesforce performance planning starts with throughput, latency, and projected workload growth. API request allocations, concurrent request limits, platform event allocations, CDC allocations, and Apex governor limits are all first-class design constraints. The limits resource can expose current maximums and remaining allocations, and Salesforce publishes dedicated allocation references for API, Bulk API, Platform Events, and CDC.

Apex integration code must be bulkified. Salesforce’s best-practice material is unambiguous: triggers and request handlers should process collections, not singletons; DML and SOQL should be consolidated; and work that can cause long-running synchronous contention should move to asynchronous boundaries where appropriate. Callouts are capped per transaction, cumulative callout time is limited, and high concurrency of long-running requests can create platform-level contention.

Bulk API 2.0 is the correct default for large movement jobs, not REST loops. MuleSoft likewise expects performance tuning and realistic load validation to be part of delivery, not an afterthought. In production-scale programs, load tests should use realistic volumes, realistic downstream behavior, and production-like network conditions.

Observability, Delivery, and Testing

Integration architecture without observability is guesswork. Salesforce provides several native layers: debug logs and Apex logs for transaction-level introspection, Event Monitoring and EventLogFile for operational/security telemetry, real-time monitoring events for near-real-time reactions, platform-event usage metrics for bus consumption, and Health Check for security-posture drift. MuleSoft complements this with Runtime Manager, Anypoint Monitoring, business events, and CI-integrated MUnit testing.

Monitoring and cross-system observability

The most effective pattern is end-to-end correlation. Salesforce’s recent official guidance recommends propagating a unique request identifier through X-SFDC-REQUEST-ID for REST API calls, and Pub/Sub API supports client trace IDs for troubleshooting. ApexLog records also expose the request identifier, which allows correlation across debug logs and event logs. This is effectively distributed tracing, even if you send the telemetry to an external APM such as Datadog, New Relic, Splunk, or an OpenTelemetry pipeline. The recommendation to use external APM tooling is an architectural inference, while the correlation primitives themselves are documented by Salesforce.

Real-Time Event Monitoring also matters operationally. Salesforce documents real-time events for monitoring activity such as logins and usage anomalies, and Shield/Event Monitoring exposes detailed usage, performance, and security data through APIs and event logs. For incident response and integration troubleshooting, that is often the missing bridge between “the API call succeeded” and “the user-visible business flow failed.”

Deployment and CI/CD

For Salesforce metadata, the durable deployment primitives remain Metadata API and Salesforce CLI. CLI supports preview, validate, quick deploy, and asynchronous deployment execution, which makes it well suited to Git-based pipelines. DevOps Center adds a Salesforce-native workflow and source tracking model. For MuleSoft, CloudHub and CloudHub 2.0 deployments can be driven from Maven plugins and Runtime Manager APIs, which fit conventional CI/CD pipelines.

A strong enterprise pipeline usually has these stages: static checks, unit tests, contract/schema validation, deployment preview, metadata validation or Mule package build, integration tests against sandboxes or lower environments, performance-scale checks for critical paths, then validated quick deploy or equivalent promotion. Salesforce’s Well-Architected and testing docs explicitly encourage automated, frequent, iterative testing as part of CI/CD.

Testing strategy

Unit tests prove code behavior in isolation. Integration tests prove contract and system interplay. Load or scale tests prove non-functional viability. In Salesforce, Apex unit tests must reach minimum deployment coverage thresholds, but advanced teams should care more about architectural coverage: retries, partial-success paths, event publication, sharing/FLS enforcement, and idempotency behavior. Salesforce now also supports Apex integration tests for real service interactions in specific service categories. For MuleSoft, MUnit provides unit, integration, and functional testing and integrates with Maven/Surefire for CI.

One subtle but important security/testing point: Data Mask exists precisely because production-like test data is often needed, but using raw production data in lower environments is a security risk. Data Mask obfuscates sensitive sandbox data, though Salesforce notes masking jobs run in sandbox orgs and that Data Mask bypasses automation such as triggers and validation rules during masking.

Reference Architectures and Case Studies

Because the request does not specify an industry or named customer, the cases below are representative enterprise scenarios synthesized from Salesforce’s official decision guides and technical documentation rather than anonymized customer disclosures. They are realistic, opinionated, and directly aligned with the kinds of architectures Salesforce itself recommends.

Event-driven opportunity-to-order to ERP

This is the canonical “Opportunity becomes Closed Won, downstream order must be created” problem. Salesforce’s guidance presents several options, but the most durable architecture for scale and decoupling is: publish a business event from Salesforce, process and transform it in middleware, then create the order in ERP with retries and dead-letter handling.

flowchart LR
    A[Opportunity Closed Won in Salesforce] --> B[Flow or Apex publishes Platform Event]
    B --> C[Pub/Sub API or MuleSoft subscriber]
    C --> D[DataWeave transformation and validation]
    D --> E[ERP Order API]
    E --> F[Success or Business Error]
    F --> G[Status update to Salesforce]
    C --> H[Retry / Dead-letter queue]

Salesforce’s decision guide explicitly discusses this scenario with Platform Events, CDC, External Services, Apex Actions, MuleSoft, Heroku Connect, and Salesforce Connect variants. The event-driven variant is best when the business does not require the seller to wait on ERP completion at save time. Use Platform Events if you need a custom event contract; use CDC if the downstream system can reconstruct the necessary order-creation context from record changes plus enrichment.

External-data virtualization for customer service

A second archetype is the service or sales user who needs access to ERP or master-data records inside Salesforce, but legal, latency, or storage concerns argue against full replication. Here, Salesforce Connect creates external objects that behave like records in the UI while data remains outside Salesforce.

flowchart LR
    U[Salesforce user] --> UI[Lightning UI]
    UI --> EO[External Object]
    EO --> DS[External Data Source]
    DS --> ERP[(ERP or MDM via OData or custom adapter)]

This is the right design when data must remain external and when the source system can meet the interactive query SLA. It is the wrong design when Salesforce must own the data or continue functioning offline from the source. Salesforce’s guidance specifically recommends avoiding replication where it is unnecessary, and positions Salesforce Connect as the virtualization choice.

ERP-to-Salesforce customer replication with canonical mapping

When contact or account data is mastered in ERP and must be replicated into Salesforce, the design center shifts: deduplication and idempotency matter more than request-time UI virtualization. The strongest architecture is a middleware-led process with canonical mapping, External ID upsert, and async buffering.

flowchart LR
    ERP[(ERP)]
    ERP --> EVT[ERP event or scheduled extract]
    EVT --> MULE[MuleSoft System API]
    MULE --> MAP[Canonical mapping / DataWeave]
    MAP --> UPSERT[Salesforce upsert by External ID]
    UPSERT --> SF[(Salesforce Contact / Account)]
    UPSERT --> OBS[Metrics and correlation logs]

Salesforce’s own decision guide uses this family of scenarios to recommend MuleSoft, native APIs, and, in special Heroku-backed cases, Heroku Connect. The critical design choice is to upsert by External ID and avoid direct singleton “create or update?” branching logic at the client. Where contention exists, use async buffering and reconciliation rather than many concurrent direct writes.

When Heroku Connect is and is not the right answer

Heroku Connect is appropriate when Heroku Postgres is a real runtime datastore that must stay synchronized with Salesforce, often because mobile, web, or microservice workloads need relational access patterns that are not ideal against Salesforce APIs. But Heroku Connect is not a generic integration hub. Official docs note plan-based synchronized row limits, polling intervals, mapping behavior, Postgres connection consumption, and performance practices such as keeping mapped fields per object under control.

Advanced Interview Questions and Further Reading

Advanced interview questions with model answers

How would you choose between Platform Events and Change Data Capture for an external inventory synchronization design? Choose CDC when the consumer wants committed record deltas from Salesforce and can work with Salesforce-shaped change messages. Choose Platform Events when you need a custom business contract, cross-object payload, or semantic event such as OrderAllocated. For new pub/sub consumption, use Pub/Sub API rather than starting a new Streaming API design.

Why is external-ID upsert central to idempotent Salesforce integrations? Because retries are inevitable. External-ID upsert lets the caller say “apply this business key exactly once,” whether the record already exists or not. It turns uncertain network outcomes into deterministic write behavior and is supported across multiple Salesforce APIs. UI API idempotent writes reinforce the same principle for client-side record operations.

When would Salesforce Connect be superior to MuleSoft replication? When the business requirement is to expose external data in the Salesforce UI without persisting it in Salesforce, and when the source can meet the runtime SLA. MuleSoft replication is better when transformation, offline access, downstream automations, or independent availability from the source are required. Salesforce’s guidance explicitly recommends avoiding unnecessary replication and considering virtualization first.

What are the real risks of putting synchronous callouts directly in record-triggered logic? You expose users to downstream latency and failure, hold resources open longer, and increase the likelihood of concurrency problems and governor-limit pressure. Salesforce’s decision guide recommends asynchronous mechanisms such as future or queueable for trigger-driven callouts after DML, and Apex limits constrain callouts and cumulative timeout.

How do you preserve least privilege in a server-to-server integration? Use a dedicated integration principal, limit OAuth scopes, restrict the runtime user’s object/field permissions through permission sets, enforce sharing where appropriate, and use Named Credentials/External Credentials outbound instead of embedded secrets. Least privilege applies to both the Salesforce side and the downstream side.

Why is Pub/Sub API strategically important even if you already know CometD and Streaming API? Because Salesforce recommends Pub/Sub API for new publish/subscribe patterns. It consolidates publish, subscribe, and schema retrieval in one API, uses gRPC/HTTP2 and Avro, supports flow control, and returns final publish results rather than just intermediate queuing signals.

What changes when Shield Platform Encryption is enabled? Encryption improves protection of data at rest, but it can change behavior in some integration-related features and must be evaluated in design and testing. Salesforce’s decision guide explicitly warns that enabling Shield Platform Encryption changes certain behaviors, and broader Shield documentation covers encryption monitoring and key management.

How would you monitor event-bus consumption in a multi-consumer landscape? Query PlatformEventUsageMetric, track usage by event, client, and time segment, and combine that with correlation IDs and Event Monitoring logs. For high-scale ecosystems, make that data visible in a central operations dashboard and alert on abnormal delivery spikes or replay gaps.

Scenario-based problems

Scenario: A seller saves a deal, and the ERP order creation sometimes takes eight seconds and sometimes fails due to validation rules. What architecture do you propose? Do not keep this on the synchronous save path unless the business explicitly requires immediate ERP confirmation. Publish a Platform Event or enqueue async Apex, let MuleSoft call ERP, surface status back to Salesforce, and route business-rule errors into an exception queue or review object. If user feedback is required, show “submission accepted / processing” plus status refresh rather than blocking the transaction.

Scenario: An ERP pushes the same contact update five times after uncertain network responses. How do you guarantee correctness?** Use External ID upsert, carry a correlation ID, and optionally maintain a processed-message ledger keyed by ERP message ID. If the ERP can re-send events freely, the Salesforce side should still converge on a single correct state.

Scenario: A compliance team forbids copying customer financial data into sandboxes, but integration testing must remain realistic. What do you do?** Use Data Mask for sandbox obfuscation, classify sensitive fields, avoid using identical production data in test stages, and ensure lower environments still exercise the integration contracts with masked but shape-realistic data.

Scenario: A company has five consuming channels and three core systems. Every new project rebuilds ERP and customer transformations. What should change?** Adopt API-led connectivity with reusable System APIs for Salesforce, ERP, and identity/master data, Process APIs for orchestration, and thinner Experience APIs per channel. This reduces duplicate transformations, centralizes governance, and simplifies future channel delivery.

The highest-level design takeaway is straightforward: build transactional integrations only where users truly need synchronous outcomes, use event-driven and bulk patterns aggressively for resilience and scale, treat identity and data contracts as architecture rather than configuration, and make observability a first-class deliverable. That is the path from simply “integrated” to enterprise-grade Salesforce integration architecture.