16 Salesforce Integration Interview Questions With Answers
Work through Salesforce integration scenarios on API choice, authentication, duplicate requests, partial failures, reconciliation and observability.
These practice questions test integration reasoning, not memorised API names. A useful answer states the business event, required consistency, expected volume and failure behaviour before naming a technology. Use fictional records and a non-production environment for demonstrations.
Prepare one complete integration story
Describe a single flow such as syncing an approved order to a fulfilment system. Draw the source of truth, authentication boundary, correlation ID, retry path and reconciliation job. Explain what happens if the request succeeds remotely but the response never reaches Salesforce.
Interview questions & answers
Design
1.How do you choose between synchronous and asynchronous integration?
Use the user’s need for an immediate result, expected response time and failure tolerance to guide the decision. A synchronous credit check can block a transaction until a result arrives. A non-urgent warehouse update may be queued. Explain how the user sees pending or failed work and how the systems reconcile.
2.How do you decide which system owns a field?
Assign a source of truth for each shared field and document permitted update directions. For example, Salesforce may own account relationship notes while a billing system owns invoice status. Specify conflict handling and deletion behaviour. Two systems updating the same value without an ownership rule can create endless overwrite loops.
3.When would you consider Bulk API rather than one request per record?
Consider bulk processing for a suitable large asynchronous data operation. Evaluate supported objects and operations, job processing time and the required error handling. A large import needs success, failure and unprocessed-record reconciliation. The smallest number of HTTP requests is not the only design criterion.
Security
1.How should an integration store endpoint and authentication configuration?
Use the appropriate named credential and external credential configuration rather than embedding secrets in Apex or a repository. Map the required principal access and permissions, separate environments, and plan credential rotation. Verify that the integration user can perform only the intended operations.
2.What would you investigate after repeated authentication failures?
Check the target environment, token lifecycle, principal configuration, required scopes and access changes. Compare a known working request without exposing token values in logs. Distinguish an expired credential from an authorisation failure. Repeatedly retrying invalid credentials adds traffic without repairing the configuration.
Reliability
1.The remote system created an order but Salesforce timed out. Should you retry?
First design an idempotent operation using a stable business key or request identifier supported by the receiver. After an ambiguous timeout, query or reconcile the outcome rather than blindly creating another order. If the receiver cannot deduplicate, the integration needs an explicit recovery process for uncertain results.
2.Which errors should an integration retry?
Classify the error. A temporary unavailable response may justify bounded retries with backoff and jitter. Invalid data or insufficient permissions usually needs correction. Honour applicable server retry guidance, cap attempts, and send exhausted work to an observable recovery queue. Avoid retry storms during a shared outage.
3.How do you handle a partially successful bulk job?
Read the successful, failed and unprocessed results and map each row back to the input. Failed rows were attempted and need their errors reviewed; unprocessed rows were not processed by that job. Retry only the appropriate records after fixing the cause, then reconcile the final outcome.
4.How would you recover from missing integration events?
Maintain a reconciliation process against authoritative records, using a suitable watermark or business-state comparison. Define how the consumer detects gaps, replays supported events and deduplicates repeats. Do not assume an event stream removes the need to verify that both systems eventually contain the required state.
5.How do you prevent updates from looping between two systems?
Define ownership and change-detection rules, and attach origin or version information when appropriate. Ignore an echoed update when it introduces no new authoritative change. Test two simultaneous edits and delayed messages. A blanket rule that ignores all integration-user changes may also suppress legitimate downstream work.
Data
1.How would you map external IDs?
Choose a stable identifier from the authoritative source, define uniqueness and case handling, and use it consistently for matching or upsert where supported. Keep display names separate from identity. Test missing IDs, duplicate IDs and source-system merges before relying on the mapping for production updates.
2.What should happen when the source deletes a customer record?
Agree a deletion policy with the data owners. The target may need a tombstone, deactivation, anonymisation or deletion depending on the business and retention requirements. Test linked records and delayed messages so an old update cannot silently recreate data that should remain removed.
Operations
1.What would you log for an integration transaction?
Log a correlation identifier, operation, timing, outcome and safe error classification. Record enough business context to locate the affected item without dumping sensitive payloads or tokens. Connect request logs to retry and reconciliation records so support can distinguish pending, successful, failed and uncertain outcomes.
2.How do you investigate an integration that slows down at month end?
Compare volume, batch size, latency, throttling, retries and target processing time across normal and peak periods. Inspect the actual limits applicable to the org and API. Reproduce the workload in a safe test where possible. Optimise the bottleneck rather than simply raising concurrency.
Testing
1.What belongs in an integration test plan?
Include valid and invalid payloads, authentication failure, timeout after remote success, duplicate delivery, out-of-order updates, partial processing and rate limiting. Verify both business records and recovery behaviour. Mocks help isolate tests, but a representative environment test is needed to validate real configuration and contracts.
Delivery
1.How would you cut over an integration safely?
Inventory existing jobs, establish a reconciliation baseline and define a controlled activation window. Verify credentials and mappings in the target environment, monitor the first batch, and keep a rollback or pause procedure. Account for queued work during the switch so disabling one path does not lose transactions.
Check your own material with the Free interview answer grader.
