20 Salesforce Integration and System Design Interview Questions

Strong answer

I ask for the business action, actors, systems, source of truth, data classification, and measurable nonfunctional requirements. “Real time” becomes a latency target such as “95% of accepted orders reach the ERP within 60 seconds.” “High volume” becomes an average, peak, burst shape, payload size, and growth forecast.

I clarify whether the caller needs a business result or only acknowledgement, whether records must be processed in order, whether partial success is acceptable, and what happens when either system is unavailable. I ask for recovery-time and recovery-point objectives, retention, audit, data-residency, and maintenance-window constraints.

Finally, I identify ownership and support boundaries: who owns the API contract, credentials, middleware, Salesforce automation, downstream service, alerts, dead-letter queue, reconciliation job, and incident response. Without those answers, a technology diagram is only a guess.

Strong answer

I define ownership per business attribute, not merely per object. Salesforce may own sales-entered delivery instructions while the ERP owns order number, credit status, allocation, and fulfillment state. A written ownership matrix states which system may create, update, correct, and publish each field.

I assign stable cross-system identifiers and store the authoritative external ID in Salesforce. Consumers use that ID for upsert and correlation rather than matching on names or mutable business values. Where a field can change in both systems, I require a conflict policy: source priority, version comparison, explicit merge, or human review.

This prevents sync loops and silent overwrites. “Last write wins” is not a default design; it is a business decision with data-loss consequences. I also define how deletes, merges, reparenting, and identity corrections propagate.

Strong answer

I model average and peak requests per second, burst duration, daily records, payload size, fan-out, API calls per business transaction, event deliveries per consumer, and retry amplification. Ten thousand orders do not equal ten thousand API calls if every order requires five lookups and three writes.

Then I map the workload to current org allocations and transactional limits: API request allocation, concurrent processing, event publishing and delivery, Bulk API jobs, Apex callouts, CPU, heap, SOQL, DML, and downstream quotas. I read the org’s /limits resource and product-specific documentation rather than copying limits from an old diagram.

I reserve operating headroom, define rate limits at ingress, and test the burst—not only the daily average. If the consumer can process 50 messages per second while the producer can emit 500, the design needs buffering, flow control, backlog alerts, and a time-to-drain calculation.

Strong answer

I use synchronous request–reply only when the caller cannot continue without an immediate result and the dependency can meet the latency and availability target. I use asynchronous messaging when work can complete later, traffic is bursty, systems must be decoupled, or durable retry and replay are more important than immediate completion.

Many real designs are hybrid. An order submission can synchronously validate required input and return an accepted command ID, then asynchronously create the ERP order. Salesforce shows a processing state and receives a later fulfillment update. The user does not wait for the ERP, but the business still gets a traceable result.

I explain the trade-off: synchronous design is simple for the caller but couples availability and latency. Async improves resilience and buffering but introduces eventual consistency, duplicate delivery, ordering decisions, separate failure monitoring, and a status experience.

Strong answer

I use a direct connection for a bounded integration between two systems when the contract, transformation, retry behavior, security, and operations remain simple. I introduce middleware when several systems need routing, orchestration, canonical transformation, protocol mediation, centralized throttling, durable queues, shared policy enforcement, or enterprise observability.

The decision is about responsibility, not fashion. Middleware can reduce point-to-point coupling but becomes another production platform with its own availability, capacity, security, deployment, and support costs. I do not move business ownership into a generic integration layer merely to keep Salesforce code small.

I draw the failure domains. If middleware is unavailable, can Salesforce accept commands durably? If the ERP is unavailable, where does the backlog live? Which team replays it, and how is the replay made idempotent?

Strong answer

I start with the interaction shape. REST resources fit ordinary record operations and queries. Composite resources reduce round trips for a small related request and can pass one subrequest’s result into another. Composite Graph fits more complex groups of dependent record operations with atomic behavior inside each graph. Bulk API 2.0 fits large asynchronous ingest, upsert, delete, and query workloads. Pub/Sub API fits event publishing and subscription for Platform Events and Change Data Capture.

I do not choose an API by record count alone. I evaluate latency, transactionality, dependency between records, partial-failure needs, payload size, query selectivity, client capability, retry behavior, and operational ownership.

The interview answer should name the rejected alternatives. For example, Bulk API 2.0 is strong for a large nightly upsert but adds job lifecycle and result-file handling that is unnecessary for a user waiting on one record.

Strong answer

I separate the initial load from the delta stream but connect them with a controlled watermark. First I clean and map source data, provision unique external IDs, load parents before dependent children, and use Bulk API 2.0 upsert for large datasets. I retain successful, failed, and unprocessed results and reconcile counts and business totals.

Before the load begins, I capture a source-system change watermark or start a durable change feed. After the baseline is accepted, I apply changes that occurred after that watermark in deterministic order. Then I switch to normal continuous processing.

The cutover plan defines freeze or dual-write behavior, validation queries, ownership transfer, rollback criteria, and how to replay the delta without duplicates. I test with production-shaped data, skewed parents, automation enabled, and the same integration identity used in production.

Strong answer

First I confirm whether the business truly requires all records to commit or none. If standard record APIs satisfy the validation and security requirements, Composite or Composite Graph can express dependencies and atomic groups without a custom endpoint. Reference IDs connect child operations to records created earlier in the request.

If the transaction requires domain logic that standard resources cannot express safely, I consider a narrow Apex REST service with a versioned contract. It validates the complete request, applies explicit user or system access decisions, performs bulk-safe work, returns stable business error codes, and never exposes internal exceptions.

I keep the atomic boundary small. A graph containing hundreds of unrelated customers creates a large blast radius when one fails. Independent business aggregates should be independent graphs or requests so failure isolation and replay remain manageable.

Strong answer

I copy data when Salesforce automation, reporting, search, offline access, sharing, low-latency reads, or historical analysis requires a local record. I consider virtualization when the external system must remain authoritative, the dataset is large or changes rapidly, users need only occasional real-time access, and the supported external-data capability meets query and security needs.

Copying creates synchronization, storage, deletion, reconciliation, and data-residency obligations. Virtualization couples the user experience to remote availability and latency and may limit Salesforce features available on the data.

I often use a hybrid: store the minimal customer or order summary needed for Salesforce workflows, keep detailed transactions in the source, and retrieve detail on demand. The design documents freshness and what users may do when the source is unavailable.

Strong answer

I use Change Data Capture when consumers need to know that Salesforce records changed. I use a custom Platform Event when Salesforce must publish an explicit business fact or command such as Order_Submitted__e with a deliberate payload and lifecycle.

CDC communicates data change, not necessarily business intent. An Opportunity update can occur for many reasons; a fulfillment request should be explicit. A custom event also gives the team control over its semantic contract, while CDC naturally follows enabled object changes.

I define publish timing. For a business event that must describe committed Salesforce data, I use an after-commit publication model so consumers do not act on a transaction that later rolls back. I also define retention-gap recovery because event replay is finite.

Strong answer

I do not promise distributed exactly-once side effects from delivery alone. Networks time out, acknowledgements are lost, and brokers or clients can redeliver. I design for at-least-once delivery with an idempotent receiver.

Every logical command carries a stable idempotency key that remains the same across retries. The receiver stores that key and its result in a durable uniqueness boundary. If the command returns, the receiver returns the original result instead of repeating payment, order creation, or inventory reservation.

For record synchronization, a unique external ID plus upsert is often the right foundation. For business commands, I also persist command state because two different commands can target the same record legitimately. I explain where the deduplication record is stored, how long it lives, and how concurrent duplicate requests are serialized.

Strong answer

First I ask whether global order is required or only order per business aggregate such as one Order. Global serialization destroys throughput and is rarely necessary. For per-order ordering, the contract includes aggregate ID and source version or sequence.

The receiver rejects, defers, or reconciles stale versions rather than letting a late Shipped event be overwritten by an earlier Packed event. Updates are made idempotent, and optimistic concurrency or a version check protects a newer state from an older write.

I also design for Salesforce locking. Events for the same Account can cause concurrent child processing and row locks even if event delivery order is correct. Partitioning, consistent parent-lock order, smaller transactions, bounded retry, and per-aggregate serialization can reduce contention.

Strong answer

I put a durable boundary between producer and consumer so the Salesforce transaction does not wait for a slow destination. The consumer uses Pub/Sub API flow control or the middleware equivalent to request only the events it can process. It scales within downstream quotas rather than pulling an unlimited backlog and failing repeatedly.

I monitor backlog age, not only queue length. A thousand messages can be healthy at high throughput or a severe breach at low throughput. Alerts include oldest-message age, processing rate, retry rate, poison messages, and estimated time to drain.

Recovery uses bounded retries with backoff and jitter for transient failures. Permanent validation or authorization failures go to a durable failed state with an owner and safe replay action. Circuit breaking prevents a failing dependency from turning every message into an immediate retry storm.

Strong answer

Replay handles an interruption while events remain in the retention window. It does not prove that a subscriber applied every business change correctly, and it cannot recover a gap older than retention. Replay IDs are opaque positions; they are not business identifiers or permanent audit keys.

The subscriber stores progress only after durable processing succeeds. It also deduplicates using an event or business ID because replay can deliver an event again.

Reconciliation compares authoritative business state across systems: missing orders, mismatched totals, stale statuses, or commands marked sent without a downstream result. It runs on a schedule and on demand after incidents, produces an explainable variance report, and repairs through the same idempotent path used by normal processing.

Strong answer

I keep the contract explicit, minimal, and safe. A useful envelope includes stable event ID, event type, schema version, source, occurred-at time, correlation ID, aggregate ID, and an aggregate version when ordering matters.

{
  "eventId": "8cc4b3e2-8dd2-4ab1-9cb1-8abeb7e75f10",
  "eventType": "OrderSubmitted",
  "schemaVersion": 1,
  "source": "salesforce",
  "occurredAt": "2026-11-02T08:00:00Z",
  "correlationId": "order-2026-000184",
  "aggregateId": "order-2026-000184",
  "aggregateVersion": 7,
  "payload": {
    "currency": "INR",
    "total": 12500.00
  }
}

The example values are synthetic. I exclude secrets and unnecessary personal data, document required versus optional fields, define null and enum behavior, and decide whether consumers receive a state snapshot or must query for detail. A large event carrying an entire record graph increases coupling and data-exposure risk.

Strong answer

For inbound system-to-system access, I give each integration its own API-only Salesforce identity and client application. That creates independent permissions, audit history, rotation, revocation, and blast radius. I never use a human administrator’s account as a shared integration identity.

I choose an OAuth flow supported by the client and trust model. OAuth client credentials can fit a confidential headless service that always runs as one configured integration user. Other scenarios may require a different OAuth flow or certificate-based approach. I document token lifetime, rotation, allowlisting, network controls, and emergency revocation.

The identity receives only the object, field, record, Apex class, and API permissions required by the contract. API-only access limits UI use; it does not automatically make broad data permissions safe.

Strong answer

For outbound callouts I use the current Named Credential and External Credential model. The Named Credential defines the endpoint and transport, while the External Credential defines authentication and principals. Sensitive material is provisioned per environment and never stored in Apex, Custom Metadata, source control, logs, or the payload.

For inbound custom APIs I authenticate the caller, authorize the exact operation, validate schema and size, use allowlisted fields, bind query inputs, apply bulk limits, and return stable errors without stack traces. I explicitly choose user-mode or controlled system-mode data operations and enforce record, object, and field access according to the service contract.

I also protect availability: request-size limits, rate limits, timeouts, idempotency, and abuse monitoring are part of security. A correctly authenticated client can still overload or misuse an endpoint.

Strong answer

I distinguish compatible and breaking change. Adding an optional field is usually compatible when consumers ignore unknown fields. Renaming or removing a field, changing meaning, tightening validation, or changing enum behavior can be breaking.

Contracts are stored in source control with examples, schemas, ownership, compatibility rules, and a changelog. Consumer contract tests run in CI. A breaking change gets a new endpoint, event type, or schema version, and the old and new versions coexist through a measured migration window.

I inventory consumers and require usage telemetry before retirement. A calendar date alone is not proof that all consumers migrated. The deprecation plan defines communication, test environments, traffic comparison, rollback, and final disablement.

Strong answer

Every business operation carries a correlation ID across Salesforce, middleware, and the destination. Structured logs record component, operation, version, sanitized business key, attempt, duration, outcome, and error category. Metrics cover throughput, success rate, latency percentiles, queue age, retries, dead letters, API and event allocation use, and reconciliation variance.

Testing includes contract, mapping, security, bulk, performance, concurrency, idempotency, ordering, timeout, duplicate delivery, malformed payload, token failure, downstream throttling, consumer outage, replay, retention-gap reconciliation, and disaster recovery. I test with production-shaped data and the real execution identities.

Go-live evidence includes agreed service-level indicators, alert thresholds, dashboards, on-call ownership, runbooks, safe replay, data repair, cutover rehearsal, and rollback. An HTTP 200 test proves connectivity, not system reliability.

Strong answer

I begin with assumptions: Salesforce owns the sales submission; the ERP owns the official order number, inventory allocation, and fulfillment status; users need immediate validation but can tolerate asynchronous creation; peak volume and recovery targets are measured; duplicate ERP orders are unacceptable.

Proposed flow

1. A user submits an Order through Salesforce. Validation confirms required data, permissions, product eligibility, and a stable customer/ERP key.
2. Salesforce creates an immutable command ID and changes the Order to Submission Pending in the same transaction.
3. After commit, Salesforce publishes an OrderSubmitted business event containing the command ID, Salesforce Order ID, version, correlation ID, and the minimal approved payload—or middleware retrieves detail using the ID.
4. Middleware consumes with flow control, validates the schema, enriches or transforms the command, and calls the ERP with the same command ID as its idempotency key.
5. The ERP stores that key in a unique boundary. A duplicate command returns the original ERP order result without creating another order.
6. Middleware publishes or calls back a versioned result. Salesforce upserts the status using the command ID and ERP external ID, rejects stale status versions, and records the latest processing state.
7. Transient failures receive bounded backoff. Permanent validation failures enter a durable recovery queue with sanitized context, ownership, and a replay action that preserves the command ID.
8. A reconciliation job compares Salesforce submitted orders with ERP accepted orders and fulfillment states. It repairs missing results through the same idempotent path.

Salesforce Order
  -> after-commit OrderSubmitted event
  -> middleware durable consumer + transformation
  -> ERP idempotent order API
  -> versioned status result
  -> Salesforce status upsert

Cross-cutting: OAuth identities, least privilege, correlation IDs,
metrics, dead-letter handling, replay, reconciliation, and runbooks

Design trade-offs

The asynchronous boundary prevents ERP latency from blocking Salesforce and absorbs traffic spikes, but users see a processing state rather than an immediate ERP number. If the business truly requires an instant inventory quote, I separate that read-only synchronous check from the idempotent asynchronous order command.

I avoid dual ownership. Salesforce may cancel a pending request, but once the ERP accepts the order, cancellation becomes a new ERP command rather than a direct Salesforce status overwrite. Contract versions allow both systems to deploy independently.

Verification

I test a normal order, duplicate submission, timeout after ERP acceptance, out-of-order status, stale update, token expiry, schema incompatibility, ERP outage, backlog recovery, replay, and reconciliation after the event-retention window. I load-test the measured peak plus retry amplification and verify that no test produces two ERP orders for one command ID.