Mastering the Matrix: Top 10 Advanced Salesforce Integration Interview Questions

Designing integrations in Salesforce is straightforward when everything goes right. But true senior developers and architects are defined by how they handle system failures, governance limits, and data integrity when things break down.

If you are preparing for a senior-level Salesforce interview or looking to build bulletproof systems, these 10 advanced integration questions from the SF Interview Pro Guide explore the deep architectural decisions that separate the juniors from the experts.

1. Why can't you make HTTP callouts directly from Apex triggers, and how do you resolve it?

The Core Problem: Salesforce executes triggers within an active database transaction (DML). While a database transaction remains open, Salesforce prohibits holding a thread open to wait for a response from an external system. Attempting a direct callout throws a Callout not allowed after uncommitted work exception.

The Solution: You must decouple the database commit from the external network request by pushing the callout into an asynchronous transaction using either @future(callout=true) or Queueable Apex implementing Database.AllowsCallouts. This allows the trigger's DML transaction to commit cleanly first, opening a fresh transaction context for the external call.

// ❌ WRONG: Pushing a callout inside a trigger block directly
trigger OrderTrigger on Order__c (after insert) {
    ERPService.makeCallout(Trigger.new[0].Id); // System Exception!
}

//  CORRECT: Delegating to an asynchronous Queueable job
trigger OrderTrigger on Order__c (after insert) {
    Set<Id> orderIds = new Map<Id, Order__c>(Trigger.new).keySet();
    System.enqueueJob(new AsyncERPCalloutQueue(orderIds)); 
}

2. What is the Circuit Breaker Pattern, and how do you design it in Salesforce?

The Core Problem: When a major downstream system goes down for maintenance, automated Apex retries or user actions continue firing callouts. This causes thousands of concurrent transaction timeouts, locking up async queues, exhausting daily API limits, and degrading org performance.

The Solution: The Circuit Breaker acts like an electrical fuse, tracking the health of an external endpoint using a state machine stored in Custom Metadata with three distinct states:

• Closed (Normal Operations): Traffic flows freely. If errors exceed a defined threshold (e.g., 5 consecutive 503 errors), the circuit trips.
• Open (System Down): The circuit fails fast. Any code attempting a callout immediately terminates or logs an error locally before making an HTTP request.
• Half-Open (Testing Recovery): After a cooldown window, the circuit allows a single "test" request through. If it succeeds, the circuit closes; if it fails, it trips back to Open.

Architectural Tip: Implementing a circuit breaker ensures your system gracefully degrades, preserving Salesforce governor resources when external platforms are completely unreachable.

3. What is Idempotency, and how do you guarantee it in an integration?

The Core Problem: Network drops are inevitable. If an external system sends a payload to Salesforce to create an invoice, but the connection drops before Salesforce can return a success response, the external system will retry. Without safety logic, that retry creates duplicate records.

The Solution: An integration is idempotent if an operation yields identical results whether executed once or 100 times.

1. Inbound: Enforce the use of an External ID on target records. Use upsert mapped against that external key. If the system retries, Salesforce safely updates the existing record rather than creating a duplicate.
2. Outbound: Include a unique transaction UUID in your custom request headers (e.g., Idempotency-Key) so the receiving system knows to ignore duplicate processing workflows.

4. Platform Events vs. Change Data Capture (CDC): When do you use which?

The Core Problem: Both architectural patterns run asynchronously on Salesforce's streaming event bus, leading developers to mistakenly treat them as interchangeable options.

The Solution: Base your decision on whether your architectural requirement is driven by data synchronization or business orchestration:

Feature	Change Data Capture (CDC)	Platform Events
Publishing	Declarative & Automatic (Fires on record Create, Update, Delete).	Programmatic (Explicitly fired via Code, Flow, or Apex using EventBus.publish()).
Payload	Rigid. Automatically includes changed fields and operational headers.	Custom-designed schema fields (__e) customized fully by the developer.
Best Use Case	Data Replication and real-time syncing with warehouses.	Automating complex, decoupled multi-system workflows.

5. How do you design an integration infrastructure to survive extended external downtime?

The Core Problem: If a receiving target system goes offline for hours or a weekend, a standard request-reply API framework fails immediately, dropping payloads unless manual, error-prone record updates are orchestrated.

The Solution: Build an event-driven architecture using **Platform Events**. Salesforce's event bus features a built-in 72-hour Event Replay window, offering an outstanding data buffer buffer out of the box.

[SF Trigger/Flow Actions] ➔ [Event Bus Published]
⬇
(External System Offline) ➔ [Events Retained up to 72 Hours]
⬇
(System Reconnects) ➔ [Replay from Last Verified ReplayId]

When your middleware or external subscriber finishes its maintenance window and reconnects, it simply passes its last successfully processed ReplayId. Salesforce automatically streams the missed messages in chronological order, achieving catch-up with zero data loss.

6. How do you handle OAuth token expiry gracefully without messy exception handling blocks?

The Core Problem: OAuth access tokens expire quickly for security reasons. Writing custom Apex code to explicitly catch 401 Unauthorized errors, run a secondary token refresh request, parse the new string, and re-fire the original callout creates a bloated codebase.

The Solution: Delegate your credential lifecycle management to Named Credentials. When configured, Salesforce natively encapsulates the OAuth handshake behind the scenes:

// ❌ WRONG: Hardcoding endpoints and manual token handling
req.setEndpoint('https://api.system.com/v1/data');
req.setHeader('Authorization', 'Bearer ' + manuallyStoredToken);

//  CORRECT: Named Credential handles endpoint encryption and auto-refresh loops
req.setEndpoint('callout:My_Secure_Endpoint/v1/data');

Named Credentials bypass the need for configuring Remote Site Settings, securely encrypt authentication parameters, and automate token-refresh loops without requiring single lines of custom utility code.

7. How do you resolve conflicts and prevent infinite loops in a bidirectional sync?

The Core Problem: If Salesforce updates an Account, it fires an outbound integration to an ERP. The ERP records the update and passes an acknowledgment change payload back to Salesforce. Without mitigation, this triggers an infinite mirroring loop that rapidly drains API allocations.

The Solution: Implement tracking parameters and master record maps:

• Loop Prevention: Add a tracking field (e.g., Last_Updated_By_System__c). When Salesforce makes an outbound push, stamp it "Salesforce". When the external app calls in, check the incoming indicator flag to suppress redundant outbound workflow rules.
• Conflict Resolution: Establish a strict, domain-based **System of Record (SoR)** matrix before writing code (e.g., Salesforce owns Lead details; ERP owns Financial parameters). Use high-precision timestamps for field overlaps to enforce a "Last Write Wins" validation check.

8. What is the sObject Collections API, and why is it vital for high-volume REST integrations?

The Core Problem: Standard single REST operations handle unique record actions sequentially. If an external system attempts to update 200 records via 200 separate HTTP calls within a tight loop, it creates major processing overhead and triggers 24-hour API limit exhaustion.

The Solution: The sObject Collections API allows external clients to bundle mass DML operations (POST, PATCH, DELETE) for up to 200 records within a single HTTP request payload.

/* PATCH /services/data/v62.0/composite/sobjects */
{
  "allOrNone" : false,
  "records" : [
    { "attributes" : {"type" : "Account"}, "Name" : "Acme East", "SAP_Customer_No__c" : "SAP-991" },
    { "attributes" : {"type" : "Account"}, "Name" : "Acme West", "SAP_Customer_No__c" : "SAP-992" }
  ]
}

Setting allOrNone: false allows partial record success, logging individual failures inside an array block response while updating valid objects. This simple design step yields an immediate **200x reduction in API call consumption**.

9. How do you securely design a Payment Gateway integration while maintaining PCI-DSS compliance?

The Core Problem: Passing, manipulating, or saving raw credit card numbers or security CVV codes within a Salesforce environment triggers extensive, highly restricted legal liabilities under annual PCI-DSS regulatory compliance audits.

The Solution: Structure your user interfaces so raw credit card parameters **never touch Salesforce servers**. Implement client-side tokenization:

Secure Tokenization Architecture Flow:
1. User inputs details into a Lightning Web Component (LWC) hosting the gateway's secure iframe SDK (e.g., Stripe.js).
2. The SDK sends data straight to the gateway from the browser, bypassing Salesforce servers, and returns a secure token reference key.
3. The LWC sends only that token key to Apex, which processes the transaction charge safely via an encrypted Named Credential callout.

10. How do you handle complex parent-child relationships efficiently during heavy data migrations?

The Core Problem: When processing high-volume record migrations containing complex parent-child structures, standard approaches require importing parents first, exporting the new Salesforce 18-digit IDs, performing spreadsheet mapping lookups, and running the child files. This is slow and tedious.

The Solution: Leverage **External ID relationship columns** natively supported by the Bulk API and Data Loader. This eliminates the need to pre-extract generated Salesforce record keys.

If your parent Accounts use an indexed External ID field called SAP_Customer_No__c, you can structure your child Contact upload CSV file like this:

FirstName	LastName	Account:SAP_Customer_No__c
Sarah	Connor	CUST-99011
John	Doe	CUST-44012

During processing execution, Salesforce automatically resolves parent links on the fly, accurately tying the child Contact to the matching Account record using the external key configurations.

Conclusion

Building great integrations requires looking past the basic "happy path." By mastering these architectural patterns—from idempotency to circuit breakers and browser tokenization—you ensure your enterprise Salesforce footprint remains resilient and highly secure.

Which of these advanced patterns have you implemented in your enterprise architectures? Let's discuss in the comments below!