15 Salesforce Integration Interview Questions and Answers

Strong answer

I choose synchronous request–reply when the user or calling process needs an immediate result and both systems can meet the latency and availability requirement. I choose asynchronous messaging when work can finish later, traffic can spike, systems need looser coupling, or retries and replay matter more than an immediate response.

I translate “real time” into a measurable requirement. A user waiting for an eligibility decision may require a synchronous response. Sending a won Opportunity to fulfillment usually does not need to block the Salesforce transaction and is often safer as an event or queued job.

I also define the timeout behavior. If the caller does not receive a response, the outcome is unknown—not automatically failed—so the design needs idempotency or a status lookup before repeating the side effect.

Strong answer

For individual records and ordinary CRUD, REST resources are a natural fit. For a small set of related operations where one response feeds another, Composite resources can reduce round trips and express dependencies. For large asynchronous ingest, update, upsert, delete, or query workloads, I consider Bulk API 2.0.

The deciding factor is workload shape, not which API I know best. Bulk API adds job-management overhead and is not automatically better for small interactive operations. Composite reduces network calls but still requires a clear partial-failure strategy. For upserts, I define an External ID and matching contract before loading data.

Strong answer

I introduce middleware when several systems need orchestration, canonical transformations, protocol mediation, centralized retries, throttling, routing, or shared observability. Middleware is especially useful when Salesforce should not own downstream-specific branching and recovery logic.

I do not add middleware only to make the diagram look enterprise. For a well-bounded call from Salesforce to one stable service, a Named Credential and focused Apex or Flow implementation can be simpler. The trade-off is another platform to operate versus reduced coupling and centralized control.

Strong answer

First I confirm whether “atomic” truly means all records must succeed or none may persist. If standard APIs meet the requirement, I consider Composite with dependent subrequests and the appropriate rollback behavior. I use reference IDs so later subrequests can consume earlier results.

If the business transaction needs custom validation, complex orchestration, or behavior that standard resources cannot express safely, I may expose a narrow Apex REST service. That service should define one request contract, validate inputs, enforce the intended access model, and return stable business error codes. I would not expose a generic “run anything” endpoint.

Strong answer

I use the current Named Credential and External Credential model rather than hardcoding a URL, API key, client secret, or access token in Apex, Custom Metadata, or a Custom Setting.

The Named Credential defines the endpoint and transport configuration. The External Credential defines the authentication protocol and principals. Principal access is mapped through profiles, permission sets, or permission set groups. I provision sensitive authentication material separately in each environment because secrets should not travel in source control.

Strong answer

I use a named principal when all approved Salesforce users or processes should call the remote service as one controlled integration identity. I use per-user authentication when the downstream system must authorize and audit each individual user separately.

The decision changes support and security. A shared integration identity is simpler to operate but needs tightly scoped permissions, credential rotation, and audit correlation back to the initiating Salesforce user. Per-user authentication preserves downstream user identity but requires every user to authenticate and introduces more token-lifecycle failure modes.

Strong answer

No. with sharing addresses record-level sharing; it does not automatically enforce object and field permissions. I define whether the endpoint should operate in user context or as a controlled integration service, then enforce that decision explicitly.

For user-context data operations I consider user-mode SOQL and DML or appropriate CRUD and field-level checks. I validate every input, use bind variables, avoid returning internal exception details, and grant the integration user only the permissions required by the contract. Authentication proves identity; it does not prove that every requested operation should be allowed.

Strong answer

Not automatically. A timeout tells me that Salesforce did not receive a complete response. It does not prove that the remote service failed to process the request.

For a read-only request, a bounded retry may be safe. For a side effect such as creating an order or taking payment, I first need an idempotent operation or a status lookup. The request carries a stable business or idempotency key, and the receiver returns the existing result when that key is seen again.

Retries should be bounded, use backoff, distinguish transient errors from permanent validation errors, and end in an observable recovery queue rather than retry forever.

Strong answer

For inbound data, I define a stable source-system identifier and store it in a unique External ID field. The integration uses upsert so the same business entity updates the existing Salesforce record instead of inserting another one.

For business commands, an External ID alone may not be enough. I also track a unique request identifier and the processing result. If the same command arrives again, the receiver returns the previous result without repeating the side effect.

I do not use a retry attempt number as the idempotency key. Every retry of the same logical operation must carry the same key.

Strong answer

I store durable request state outside the running transaction: correlation ID, target operation, sanitized payload reference, attempt count, next-attempt time, last error category, and final status. Queueable or scheduled processing can select eligible work and make the callout.

I retry only transient failures such as selected timeouts, throttling responses, or temporary service errors. Authentication, schema, and business-validation failures should stop and alert an owner. After the maximum attempts, the request moves to a failed state with a manual replay action that preserves the original idempotency key.

I also control concurrency so a recovery surge does not overload the remote service or Salesforce. The queue is an operational product: it needs ownership, dashboards, alerts, retention, and a runbook.

Strong answer

I use a custom Platform Event when the business wants to publish an explicit fact such as Order_Ready__e with a deliberate event contract. I use Change Data Capture when consumers need notifications that Salesforce records were created, updated, deleted, or undeleted.

CDC communicates record change; it does not automatically communicate business intent. An Opportunity field update may happen for many reasons, while Fulfillment_Requested__e states what downstream systems should do. The choice depends on the contract consumers need, not only on which mechanism is easier to enable.

Strong answer

The subscriber durably stores its last successfully processed replay position and requests retained events from that position when it reconnects. It acknowledges progress only after its own processing succeeds.

Replay does not remove the need for idempotency. The consumer can receive the same business event more than once, so it should deduplicate using a durable message or business identifier. I also design for the case where the outage lasts beyond the event-retention window: run a reconciliation query or bulk extract to rebuild the missing state.

Strong answer

I define field-level ownership first. If Salesforce owns customer status and the ERP owns credit status, each side publishes only changes it owns. I carry source-system and correlation metadata so a consumer can recognize its own echoed update.

I compare meaningful values before writing, avoid updates that make no actual change, and use stable external identifiers. A blanket “integration user changed it, so ignore it” rule can hide legitimate work and breaks when several integrations share an identity. Ownership and correlation are safer than username-only filtering.

Strong answer

I separate payload mapping, business decisions, and transport code so most behavior can be tested without a network dependency. For the callout boundary, I use HttpCalloutMock with Test.setMock() and assert both the outbound request and the handling of the response.

The test suite includes success, validation error, authentication failure, throttling, server error, timeout-equivalent exception, malformed JSON, empty body, and duplicate retry behavior. I assert durable state and business outcomes—not only code coverage.

Credential configuration is also tested in a sandbox or target test org with least-privileged access. Unit tests prove code paths; they do not prove that an OAuth principal, endpoint, certificate, firewall, or remote permission is configured correctly.

Strong answer

I monitor business completion, not only HTTP success. The minimum operational view includes request count, success and failure rate, latency, retry count, queue age, dead-letter volume, authentication failures, API or event allocation usage, and reconciliation differences.

Every transaction carries a correlation ID across Salesforce, middleware, and the remote system. Logs avoid secrets and unnecessary customer data but preserve enough context to trace one business operation. Alerts have owners and thresholds, and the runbook explains how to replay safely.

Finally, I reconcile. For example, compare orders marked “sent” in Salesforce with orders accepted downstream. A 200 response does not guarantee that every later business step completed.