Salesforce integrations are a core focus area in modern Salesforce interviews, especially for Integration Developers, Architects, and senior technical roles. Interviewers expect you to go beyond API definitions and clearly explain integration patterns, security models, middleware choices, event-driven architectures, and real-world trade-offs under governor limits and enterprise constraints.
This guide is part of our broader Salesforce Interview Questions: The Complete Preparation Guide for Every Salesforce Role.
In today’s interconnected enterprise landscape, Salesforce rarely operates in isolation. Organizations demand professionals who can seamlessly connect Salesforce with their ecosystem of applications, databases, and external systems. Whether you’re aiming for a Salesforce Integration Architect role, Integration Developer position, or simply want to strengthen your integration expertise, mastering interview questions is your gateway to success.
This comprehensive guide covers everything you need to know about Salesforce integration interview questions, from foundational concepts to advanced architectural patterns that will set you apart from other candidates.
Why Integration Skills Matter More Than Ever?
The Salesforce ecosystem has evolved from a standalone CRM to the cornerstone of digital transformation strategies. Today’s organizations require seamless data flow between Salesforce and ERP systems, marketing automation platforms, legacy databases, payment gateways, and countless other applications.
Integration expertise is often what differentiates a Salesforce Developer from a Salesforce Architect. If you’re earlier in your journey, reviewing Salesforce Admin Interview Questions & Answers can help you build foundational system knowledge before tackling integrations.Â
Foundational Integration Concepts
Before diving into advanced questions, interviewers expect strong fundamentals around APIs, data consistency, and system boundaries. These concepts also frequently appear in Salesforce Admin Technical Interview Questions, especially when admins work with external tools.
What is System Integration?
System integration is the process of connecting disparate applications, databases, and systems to enable seamless data exchange and unified business processes. In enterprise contexts, integration eliminates data silos, reduces manual data entry, ensures data consistency, and enables real-time decision-making based on comprehensive information.
Integration Architecture Principles
Modern integration follows key architectural principles: loose coupling ensures systems remain independent and changes don’t cascade, abstraction hides implementation details behind consistent interfaces, scalability allows handling increasing volumes without redesign, reliability ensures consistent performance even during failures, and security protects data throughout its journey between systems.
Core Salesforce Integration Interview Questions
Question 1: Explain the different integration options available in Salesforce
Sample Answer: Salesforce provides multiple integration approaches, each suited for different scenarios. REST API uses HTTP protocols and lightweight JSON payloads, ideal for mobile applications and modern web services. SOAP API offers a more structured, contract-based approach using WSDL definitions, preferred for enterprise integrations requiring strong typing. Bulk API handles large data volumes through asynchronous batch processing, perfect for data migrations or nightly synchronizations.
Streaming API enables real-time push notifications using Bayeux protocol, eliminating the need for polling. Additionally, we have specialized APIs like Metadata API for deployment automation, Tooling API for building development tools, and platform-specific APIs like Chatter REST API for social features. The choice depends on factors like data volume, real-time requirements, security needs, and client capabilities.
Question 2: What's the difference between synchronous and asynchronous integration patterns?
Sample Answer: Synchronous integration means the calling system waits for a response before continuing execution. This works well for real-time requirements like payment processing or address validation where immediate feedback is critical.
However, it introduces tight coupling and the caller must wait for potentially slow external services. Asynchronous integration, conversely, sends requests without waiting for immediate responses. The caller continues processing while the integration completes in the background.
This is ideal for time-consuming operations like data enrichment or batch updates. I typically recommend asynchronous patterns for high-volume scenarios, long-running processes, or when the calling system doesn’t need immediate results. Salesforce supports both through different mechanisms—REST callouts for synchronous, and Platform Events or outbound messages for asynchronous communication.
Question 3: Describe the role of middleware in enterprise integrations
Sample Answer: Middleware serves as the integration backbone in complex enterprise environments. It acts as a central hub that manages connections between multiple systems, providing capabilities that individual point-to-point integrations can’t easily achieve.
Key middleware functions include message routing based on content or rules, data transformation between different formats and schemas, protocol conversion when systems use incompatible communication methods, error handling and retry logic, message queuing for reliability, and comprehensive logging for troubleshooting.
Tools like MuleSoft, Dell Boomi, or Informatica exemplify enterprise middleware. Middleware becomes essential when you’re integrating more than three or four systems, need complex transformation logic, require guaranteed message delivery, or want centralized visibility into integration health. Without middleware, you’d build numerous point-to-point integrations that become a maintenance nightmare as your architecture evolves.
API and Web Services Questions
Question 4: What are the key differences between REST and SOAP APIs?
Sample Answer: REST and SOAP represent fundamentally different approaches to API design. REST is an architectural style using standard HTTP methods like GET, POST, PUT, and DELETE. It’s stateless, meaning each request contains all necessary information, and typically uses lightweight JSON for data exchange. REST excels in simplicity, performance, and compatibility with web and mobile applications.
SOAP, by contrast, is a protocol with strict standards defined through WSDL files. It uses XML exclusively and can operate over various transport protocols, not just HTTP. SOAP provides built-in error handling, stronger typing through XML Schema, and supports WS-Security standards for enterprise-grade security.
I choose REST for most modern integrations due to its simplicity and performance, particularly for mobile apps or when bandwidth is limited. SOAP becomes preferable when working with legacy enterprise systems, when strong typing prevents errors, or when advanced security features like message-level encryption are required.
Question 5: Explain WSDL and its importance in integration
Sample Answer: WSDL stands for Web Services Description Language, an XML-based definition that describes SOAP web services. It functions as a contract between the service provider and consumer, specifying exactly what operations are available, what parameters they accept, what data types they use, and where the service is located.
Salesforce provides two WSDL types: Enterprise WSDL is strongly typed and organization-specific, containing your custom objects and fields, making it ideal when integrating your specific Salesforce configuration with external systems. Partner WSDL is loosely typed and generic across all Salesforce orgs, useful when building applications that need to work with any Salesforce instance, like ISV applications.
Understanding WSDL is crucial because it enables code generation in various programming languages, provides clear service documentation, and ensures type safety that prevents runtime errors. When consuming external SOAP services, I parse their WSDL in Salesforce to generate Apex stubs that simplify callout implementation.
Question 6: How do you handle large data volumes in Salesforce integrations?
Sample Answer: “Large data volumes require strategic approaches to avoid governor limits and performance issues. Bulk API is my primary tool for high-volume scenarios—it processes records in batches asynchronously, handling up to 150 million records per day with proper implementation. For imports, I chunk data into batches of 200-2000 records depending on complexity.
For exports, I query efficiently using indexed fields and date ranges. Composite API is another valuable tool, allowing up to 25 subrequests in a single call, dramatically reducing round trips for related operations. I also leverage Platform Events for event-driven architectures that can handle high message volumes with built-in replay functionality.
Critical techniques include using efficient SOQL queries with proper indexing, implementing retry mechanisms with exponential backoff for API limits, processing data incrementally with timestamp-based deltas rather than full extracts, and monitoring API usage to stay within limits. For truly massive datasets exceeding API capacity, I evaluate Salesforce Connect for virtual integration or Change Data Capture for near-real-time synchronization.”
Authentication and Security Questions
Question 7: Explain OAuth 2.0 and its role in Salesforce integrations
Sample Answer: OAuth 2.0 is an authorization framework that enables secure, delegated access without sharing credentials. It’s the foundation of modern Salesforce integrations. The framework involves four actors: the resource owner who owns the data, the client application requesting access, the authorization server that issues tokens, and the resource server hosting protected resources.
Salesforce supports multiple OAuth flows for different scenarios. The Web Server flow suits server-side applications that can securely store credentials, using authorization codes exchanged for access tokens. Username-Password flow works for trusted applications where users enter credentials directly, though it’s discouraged due to security implications.
JWT Bearer flow enables server-to-server integration without user involvement, ideal for middleware or ETL processes. Refresh Token flow maintains long-term access by exchanging refresh tokens for new access tokens when they expire. Device Authentication flow handles devices with limited input capabilities like smart TVs. Understanding which flow fits your use case is critical—I recommend Web Server flow for web applications, JWT for backend integrations, and avoiding Username-Password flow whenever possible due to security concerns.
Question 8: What is a Connected App and how do you configure it?
Sample Answer: A Connected App is Salesforce’s framework for integrating external applications using APIs and protocols like OAuth, SAML, and OpenID Connect. It acts as a bridge between Salesforce and external systems, managing authentication and authorization.
When creating a Connected App, I first enable OAuth settings and define callback URLs where Salesforce redirects users after authentication. I select OAuth scopes carefully—granting only the minimum permissions required, like ‘Access and manage your data’ for API access or ‘Perform requests on your behalf at any time’ for refresh tokens.
For server-to-server integrations, I configure the app for JWT flow by uploading a digital certificate and identifying users who can authenticate. I also set IP restrictions and refresh token policies for security. The resulting Consumer Key and Consumer Secret form the credentials external systems use to authenticate.
Critical considerations include using separate Connected Apps for different integrations to enable granular control and monitoring, implementing proper certificate management for JWT flows, regularly reviewing and revoking unused apps, and maintaining comprehensive documentation of each app’s purpose and configuration.
Question 9: How do Named Credentials simplify integration development?
Sample Answer: Named Credentials are powerful abstractions that encapsulate endpoint URLs and authentication details in a single, reusable configuration. Instead of hardcoding endpoints and managing authentication logic in Apex, I reference a Named Credential that handles everything. This provides several crucial benefits.
First, security improves because credentials are stored securely in Salesforce, never exposed in code, and managed through profiles and permission sets. Second, portability increases since the same code works across environments—I simply update the Named Credential configuration when promoting from sandbox to production rather than modifying code.
Third, authentication is automatic—Salesforce handles OAuth token generation, refresh, and injection into callout headers. Fourth, governance improves with centralized credential management and audit trails. When implementing Named Credentials, I create separate credentials for each external system and environment combination.
For OAuth-based services, I configure the authentication protocol and credentials in the Named Credential definition. For certificate-based authentication, I upload certificates through the Certificate and Key Management interface. I also leverage Named Credentials with External Services to create declarative integrations with minimal code.
Question 10: What is the difference between OpenID Connect and OAuth 2.0?
Sample Answer: While OAuth 2.0 handles authorization—granting applications permission to access resources—OpenID Connect adds an authentication layer on top of OAuth. OAuth answers ‘What can you do?’ while OpenID Connect answers ‘Who are you?’ In practice, OAuth provides access tokens that grant permissions, while OpenID Connect adds ID tokens containing user identity information.
The ID token is a JWT that includes claims about the authenticated user like email, name, and profile picture. This distinction matters in enterprise contexts. When building single sign-on solutions, I use OpenID Connect because it authenticates users and provides their identity information.
The flow works similarly to OAuth Web Server flow but returns both an access token for API calls and an ID token containing user information. I leverage this when implementing single sign-on where Salesforce is the identity provider, or when external applications need verified user information beyond just API access permissions.
When building an integration that needs to access Salesforce data on behalf of a user, I use OAuth for authorization. Salesforce supports OpenID Connect for identity provider scenarios where Salesforce authenticates users for external applications.
Advanced Integration Architecture Questions
Question 11: Compare API Gateway versus ESB approaches
Sample Answer: API Gateways and Enterprise Service Buses serve different architectural purposes, though they’re sometimes confused. An API Gateway sits at the edge of your architecture, functioning as a single entry point for external clients accessing internal services.
It handles cross-cutting concerns like authentication, rate limiting, request routing, protocol translation, and monitoring. API Gateways excel at managing APIs as products—versioning them, monitoring usage, enforcing policies, and providing developer portals. ESB, conversely, sits inside your architecture, orchestrating communication between multiple internal systems.
It provides message routing based on content, complex data transformation, guaranteed delivery through message queuing, and orchestration of multi-step business processes. The architectural choice depends on your needs.
I recommend API Gateway when you’re exposing services to external consumers, need to manage API consumption patterns, or want to create a facade over multiple backend services. ESB becomes valuable when you have numerous internal systems requiring orchestration, need complex message transformation between systems with incompatible formats, or want centralized business process automation. Modern architectures often use both—API Gateway facing external clients and ESB handling internal integration complexity.
Question 12: Explain integration patterns and when to use each
Sample Answer: Integration patterns provide proven solutions to recurring integration challenges. I apply different patterns based on specific scenarios. Remote Process Invocation with Request-Reply fits when Salesforce needs to call an external service and wait for results—like credit checks or address validation.
The synchronous nature ensures immediate feedback but requires consideration of timeout scenarios. Fire-and-Forget suits scenarios where Salesforce triggers external processes without needing responses—like initiating shipment processing or sending data to analytics platforms.
Batch Data Synchronization handles scheduled bulk updates between systems—typically used for nightly customer master data synchronization or periodic inventory updates. This pattern accepts eventual consistency and handles large volumes efficiently.
Remote Call-In applies when external systems need to create or update Salesforce data—such as e-commerce orders creating opportunities or mobile apps updating field service records. UI Update Based on Data Changes leverages Streaming API or Platform Events to push real-time updates to user interfaces without polling—ideal for live dashboards or collaborative applications.
Data Virtualization via Salesforce Connect enables real-time access to external data without replication—perfect when you need current data from systems of record but don’t want data duplication. The pattern selection fundamentally shapes architecture, performance, and complexity.
Question 13: How do you design fault-tolerant integrations?
Sample Answer: Fault tolerance requires multiple defensive strategies working together. First, I implement comprehensive error handling with try-catch blocks that capture exceptions, log details for troubleshooting, and handle errors gracefully rather than failing silently.
Second, I use retry logic with exponential backoff—when transient errors occur like network timeouts or rate limits, the integration retries with increasing delays between attempts, typically three to five retries before ultimate failure.
Third, I implement circuit breakers that temporarily disable failing integrations to prevent cascading failures, checking periodically whether the external service has recovered. Fourth, I design for idempotency, ensuring duplicate message processing doesn’t create data inconsistencies—using unique identifiers to detect and skip already-processed records.
Fifth, I queue messages asynchronously for non-real-time integrations using Platform Events or external message queues, enabling retry and reprocessing without data loss. Sixth, I monitor actively with custom logging, monitoring dashboards, and alerting when error rates exceed thresholds.
Seventh, I implement graceful degradation where possible—if the integration fails, the system continues functioning with reduced capability rather than complete failure. Finally, I maintain detailed documentation and runbooks so operations teams can respond effectively when issues arise.
Question 14: Describe your approach to API security beyond authentication
Sample Answer: API security extends far beyond authentication. First, I implement proper authorization using OAuth scopes and Salesforce permission sets to ensure callers can only access data they’re entitled to—never relying solely on authentication without proper authorization checks.
Second, I validate all inputs rigorously, checking data types, formats, and ranges to prevent injection attacks and data corruption. Third, I implement rate limiting to prevent abuse, using both Salesforce’s built-in API limits and custom logic for additional control when needed. Fourth, I encrypt sensitive data in transit using TLS and at rest when storing credentials or PII.
Fifth, I apply IP whitelisting through Network-Based Firewall rules or Transaction Security policies, restricting API access to known, trusted network ranges. Sixth, I implement request signing for sensitive operations, ensuring message integrity and preventing man-in-the-middle attacks.
Seventh, I maintain comprehensive audit trails logging who accessed what data when, enabling security reviews and compliance reporting. Eighth, I follow least-privilege principles, granting only minimum necessary permissions. Finally, I regularly review and rotate credentials, immediately revoking access for deprecated integrations or departed employees. Security requires defense in depth—no single measure suffices.
Scenario-Based Integration Challenges
Question 15: Design an integration for synchronizing customer data between Salesforce and an ERP system
Sample Answer: This common scenario requires careful architectural decisions. I’d start by understanding requirements: synchronization frequency, data volume, which system is authoritative for which fields, and whether real-time or batch synchronization is acceptable. For a typical implementation, I’d use bidirectional synchronization with conflict resolution.
From ERP to Salesforce, if data changes frequently, I’d implement Platform Events triggered by ERP database changes, pushing updates to Salesforce near-real-time. For lower-volume scenarios, scheduled API calls querying ERP for changed records work well. From Salesforce to ERP, I’d use Platform Events published when critical fields change, or outbound messages for simpler scenarios.
The middleware layer—MuleSoft, Dell Boomi, or custom middleware—handles transformation between different data models, implements business rules for data validation, manages conflict resolution when both systems change the same record, and maintains an audit trail.
Critical considerations include identifying master data sources to prevent circular updates, implementing last-modified-wins or business-rules-based conflict resolution, handling edge cases like deleted records, maintaining data quality through validation, and monitoring synchronization health with dashboards showing lag times and error rates.
I’d implement this incrementally, starting with one-way synchronization, validating data quality, then adding bidirectional capabilities with comprehensive testing of conflict scenarios.
Question 16: How would you integrate Salesforce with a legacy system lacking modern APIs?
Sample Answer: Legacy system integration presents unique challenges requiring creative solutions. First, I’d thoroughly assess available integration points—even older systems often have database access, flat file exports, or outdated APIs that can be leveraged.
If the system exposes a database, I’d build a middleware layer that queries the database, transforms data, and exposes REST APIs for Salesforce to consume—tools like Apache Nifi or custom Java services work well here. If the system generates flat files, I’d implement scheduled processes that retrieve files via SFTP, parse them, and push data to Salesforce through Bulk API.
For systems with GUI automation as the only option, RPA tools like UiPath can automate screens, though this is fragile and should be a last resort. Modern approaches like database replication to a staging database from which APIs can be built, or deploying ESB tools that include legacy connectors, often provide better solutions.
Security becomes paramount—if exposing legacy systems, I’d ensure proper network security, implement API gateways for additional protection, and carefully validate all data. Change management is critical too—legacy systems often lack good documentation, so I’d document everything learned during integration development and maintain close relationships with stakeholders who understand the legacy system. The goal is creating a sustainable integration that doesn’t break as systems evolve.
Question 17: Design a real-time notification system for order status updates
Sample Answer: Real-time notifications demand an event-driven architecture. I’d use Platform Events as the foundation—when order status changes in Salesforce, a trigger publishes an event containing order ID, new status, timestamp, and relevant metadata. External systems subscribe to this event channel using CometD client libraries, receiving notifications in real-time without polling.
For the user interface, I’d leverage Salesforce’s Streaming API with lightning:empApi Lightning component or Platform Events with lwc:empApi, enabling live updates in user screens without page refreshes. For external system notifications—like notifying customers via email or SMS—I’d subscribe a middleware layer to the Platform Event, which then orchestrates communications through appropriate channels based on customer preferences.
Critical architectural decisions include defining event schemas carefully to include all necessary information without unnecessary payload, implementing event replay capability so subscribers can catch up after disconnections using replay IDs, handling high event volumes by designing for asynchronous processing and proper subscriber scaling, ensuring delivery guarantees by acknowledging successful processing and implementing retry logic for failures, and monitoring event publishing and subscription health through Event Monitor logs.
For truly massive scale exceeding Platform Event limits, I’d consider Change Data Capture which provides similar capabilities with higher volume thresholds. The event-driven approach decouples producers from consumers, enabling scalability and flexibility as new subscribers are added without impacting existing ones.
Real-Time Integration and Event-Driven Architecture
Question 18: Explain Platform Events and when to use them
Sample Answer: “Platform Events enable event-driven integrations by providing a publish-subscribe model for Salesforce. Unlike traditional request-response patterns, Platform Events decouple event producers from consumers—publishers send events without knowing who will consume them, and subscribers receive events they’re interested in without knowing who published them.
Platform Events offer several advantages. They’re fire-and-forget, allowing publishers to continue processing without waiting for subscriber responses. They support replay, letting subscribers retrieve missed events up to 72 hours using replay IDs. They handle high volumes with robust throughput. And they provide durability through the event bus with delivery guarantees.
I use Platform Events for scenarios requiring real-time updates without polling—like notifying external systems of Salesforce data changes immediately. They’re perfect for cross-cloud communications within Salesforce—for example, Sales Cloud publishing events that Marketing Cloud or Commerce Cloud consume.
They excel at integrating Salesforce with IoT devices or streaming platforms. And they’re ideal for implementing asynchronous processes within Salesforce itself, like triggering complex operations that would exceed governor limits in a trigger. The key differentiator from Change Data Capture is control—with Platform Events, I explicitly define when to publish and what data to include, whereas CDC automatically publishes for data changes.
I define Platform Event objects just like custom objects but with fields relevant to my business events, then publish via triggers, processes, flows, or Apex, while external systems subscribe using CometD or EventBus APIs.”
Question 19: What is Change Data Capture and how does it differ from Platform Events?
Sample Answer: Change Data Capture automatically publishes events when Salesforce records are created, updated, deleted, or undeleted. Unlike Platform Events which require explicit publishing logic, CDC works automatically once you enable it for specific objects. CDC events include all fields that changed, not just fields you specified, giving subscribers complete change information.
The event payload includes both new and old values for changed fields, enabling subscribers to understand exactly what changed. CDC also provides event headers with transaction details like change origin and commit timestamp. I use CDC when I need comprehensive data synchronization—like maintaining a data warehouse with near-real-time Salesforce data.
It’s perfect for scenarios requiring full audit trails of changes without building custom tracking. It excels when multiple external systems need to stay synchronized with Salesforce changes without custom code for each. CDC handles scenarios where you need to react to record deletion, which doesn’t work with triggers.
The trade-offs are less control over when events publish and what data they contain compared to Platform Events, and CDC counts against your event daily allocation. CDC becomes my default choice for data replication use cases, while I use Platform Events for custom business events and when I need precise control over event payload and timing. Both can coexist—I often use CDC for database synchronization and Platform Events for workflow notifications.
Question 20: How do you implement idempotency in integrations?
Sample Answer: Idempotency ensures repeated processing of the same message produces identical results, critical for reliable integrations. Network failures, retries, and asynchronous processing mean systems often receive duplicate messages. Without idempotency, you’d create duplicate records, double-charge customers, or corrupt data.
I implement idempotency through several techniques. First, unique external IDs act as natural deduplication keys—when integrating order systems, I use order numbers as external IDs on Salesforce records, then upsert using these IDs. Duplicate requests update existing records rather than creating duplicates.
Second, I implement idempotency tokens—clients generate unique UUIDs for each operation, sending them with requests. My integration stores processed tokens and rejects requests with already-seen tokens. Third, I leverage Salesforce’s upsert operation which is naturally idempotent when using external IDs.
Fourth, for financial transactions or other sensitive operations, I implement database-level locks or optimistic locking patterns to prevent race conditions. Fifth, I design processes to be naturally idempotent where possible—rather than ‘add $100 to balance,’ I set ‘balance to $1000,’ making the operation intrinsically safe for duplicate execution.
Implementation typically involves adding external ID fields to custom objects, implementing token storage using custom objects with unique constraints, adding validation logic at integration entry points to detect duplicates, and maintaining comprehensive logs so I can trace duplicate processing attempts. The investment in idempotency pays dividends in system reliability and data integrity.
Integration Tools and Middleware Questions
Question 21: Compare Salesforce Connect versus traditional data replication
Sample Answer: Salesforce Connect and data replication solve different integration challenges. Salesforce Connect creates virtual integrations—external data appears as Salesforce objects but remains stored in source systems. Queries execute in real-time against external systems via OData or custom adapters.
This provides always-current data, eliminates synchronization lag and data storage costs, and simplifies integration since there’s no replication logic to build. However, it’s limited to read and light update operations, depends on external system availability, and can be slower than querying local Salesforce data.
Data replication, conversely, copies data into Salesforce on schedules or triggers, storing it in standard or custom objects. This provides fast queries since data is local, works offline if external systems are unavailable, and supports full CRUD operations and complex relationships. But it introduces synchronization complexity, data staleness between sync cycles, and storage costs.
I choose Salesforce Connect when I need real-time access to frequently-changing external data, when the external system is the definitive data source and Salesforce is just viewing it, when data volumes are too large to store in Salesforce, or when I want to minimize integration maintenance.
I choose replication when users need fast queries, when the integration must function if external systems fail, when I need complex reporting or analytics on the data, or when business processes require creating or modifying external data through standard Salesforce UI. Hybrid approaches work too—replicate reference data for performance while using Salesforce Connect for transactional data.
Question 22: Explain Composite API and its benefits
Sample Answer:Â “Composite API executes multiple REST API requests in a single server call, dramatically reducing round trips and improving performance. Instead of making separate API calls to create an Account, three Contacts, and two Opportunities, I can bundle everything into one Composite request.
Salesforce processes the subrequests sequentially, and I can reference outputs from earlier subrequests in later ones using reference IDs—for example, creating an Account and then creating Contacts using the Account ID from the first operation. This solves critical challenges.
First, it reduces API call consumption—one Composite call counts as one API call plus the subrequests, but you’re still saving tremendous overhead. Second, it improves performance by eliminating network latency of multiple round trips. Third, it enables atomic operations—if I set allOrNone to true, either all operations succeed or all fail, preventing partial updates.
Fourth, it simplifies client code by managing related operations in single requests. Composite API comes in two flavors: standard Composite for executing any REST API requests, and Composite Batch for parallel execution when operations are independent.
I use Composite heavily when building integration middleware that orchestrates multiple Salesforce operations, when mobile or web applications need to minimize network requests, or when performing complex data operations that would otherwise require numerous sequential API calls. The limit is 25 subrequests per Composite call, which handles most practical scenarios while preventing abuse.”
Question 23: How do you use Tooling API in integration scenarios?
Sample Answer: Tooling API enables programmatic access to Salesforce metadata and development tools, opening unique integration possibilities. Unlike Metadata API which operates on complete metadata files, Tooling API provides fine-grained access to individual metadata components, making it faster for specific operations. I use Tooling API in several scenarios.
First, building custom development tools—like editors that modify Apex classes, Visualforce pages, or Lightning components directly through API calls. Second, implementing continuous integration pipelines that query code coverage, create test runs, and retrieve results programmatically.
Third, creating governance tools that audit metadata—like scanning all Apex classes for security anti-patterns or enumerating permission set assignments across the org. Fourth, building custom ETL tools that need to understand org structure—like querying field definitions to dynamically construct integration mappings.
Tooling API queries return individual records from metadata tables like ApexClass, ApexTrigger, or Profile, enabling granular metadata inspection. It supports SOQL queries against these metadata objects, allowing complex filtering and joining. I can query code coverage results, retrieve debug logs programmatically, execute anonymous Apex, and even deploy individual metadata components.
The key advantage over Metadata API is speed and granularity—I can modify a single Apex class without retrieving or deploying entire packages. Use cases include developer tooling, governance automation, and integration middleware that adapts behavior based on org configuration.
Best Practices and Performance Optimization
Question 24: How do you monitor and troubleshoot integrations?
Sample Answer: Comprehensive monitoring and troubleshooting require multiple layers of visibility. First, I implement centralized logging using custom objects or external log aggregation tools like Splunk or DataDog. Every integration operation logs entry and exit points, key data values, processing times, and any errors. I include correlation IDs that trace requests across systems, enabling end-to-end transaction tracking.
Second, I leverage Salesforce’s built-in monitoring through Setup Audit Trail for administrative changes, API Usage Metering for consumption tracking, Debug Logs for real-time troubleshooting, and Event Log Files for bulk analysis.
Third, I build monitoring dashboards using Salesforce reports or external tools, visualizing key metrics like API call volume, error rates, average response times, and success rates by integration point. Fourth, I implement alerting that notifies operations teams when error rates exceed thresholds, when API limits are approaching, or when critical integrations fail.
Fifth, I maintain detailed documentation for each integration including architecture diagrams, data flows, failure scenarios, and troubleshooting runbooks. When issues occur, I follow a systematic approach: first, identify whether the problem is in Salesforce, the external system, or network connectivity.
Second, examine logs to find the error message and context. Third, reproduce the issue in a sandbox if possible. Fourth, isolate the root cause through testing. Finally, implement and validate the fix. Critical troubleshooting tools include Postman for testing API calls independently, Salesforce Workbench for exploring API responses, Developer Console for real-time log analysis, and external monitoring tools for system-level visibility.
Question 25: Describe strategies for optimizing integration performance
Sample Answer: Integration performance optimization spans multiple dimensions. First, minimize round trips—batch operations together using Bulk API or Composite API rather than making individual calls for each record. This reduces network latency and API consumption.
Second, optimize data queries—use selective filters on indexed fields, retrieve only necessary fields rather than SELECT *, and paginate large result sets properly. Third, implement caching where appropriate—if reference data changes infrequently, cache it locally rather than querying repeatedly.
Fourth, use asynchronous processing when real-time responses aren’t required—Platform Events or Queueable Apex for operations that can complete later. Fifth, leverage Salesforce’s platform capabilities—use Before-Save triggers to avoid extra DML operations, implement trigger handlers that bulkify automatically, and use Map collections for efficient record lookups.
Sixth, compress data payloads to reduce network transfer time, particularly for large JSON or XML responses. Seventh, implement connection pooling and HTTP keep-alive to reuse network connections across requests. Eighth, optimize external system APIs—ensure they’re indexed properly, return data efficiently, and support bulk operations where possible.
Ninth, monitor continuously to identify bottlenecks through timing metrics and slowly-degrading performance patterns. Tenth, design for horizontal scaling—as volumes grow, ensure architectures can distribute load across multiple servers or processes. Performance is not a one-time activity but continuous refinement as data volumes and usage patterns evolve.
Question 26: What are governor limits and how do they impact integration design?
Sample Answer: Governor limits are Salesforce’s resource consumption caps that ensure multi-tenant platform stability. They fundamentally shape integration architecture. For synchronous operations, you’re limited to 100 SOQL queries, 150 DML statements, 12MB heap size, 10 seconds CPU time, and 100 HTTP callouts per transaction.
Asynchronous operations like batch Apex or future methods have higher limits. API operations have separate limits—typically 15,000 to 100,000+ API calls per 24 hours depending on edition and licenses. These limits drive critical design decisions. First, I bulkify all operations—processing records in collections rather than individually to avoid hitting DML or SOQL limits.
Second, I use Batch Apex for high-volume processing, operating on up to 50 million records with proper chunk sizing. Third, I implement callout patterns that respect the 100-callout limit—either chaining asynchronous jobs or using Composite API to bundle operations. Fourth, I monitor consumption actively through System.
Limits methods that report current utilization within transactions. Fifth, I design for scalability from day one—architectures that work with 100 records often fail with 10,000 unless specifically designed for volume. Sixth, I implement queuing mechanisms for operations exceeding limits—using Platform Events or custom queuing to process incrementally.
Understanding limits isn’t about working around them—it’s about designing architectures that work harmoniously within platform constraints while delivering required functionality efficiently.
Question 27: How do you handle API versioning in integrations?
Sample Answer: API versioning prevents breaking changes from disrupting existing integrations while enabling platform evolution. I implement several versioning strategies. First, I explicitly specify API versions in all REST and SOAP calls rather than using defaults.
This ensures my integrations continue working even after Salesforce releases new API versions that might behave differently. Second, I test integrations against upcoming API versions during each Salesforce release cycle—major releases preview new versions months in advance.
Third, I design for backward compatibility when building custom APIs—adding new fields or endpoints rather than modifying existing ones, using optional parameters with sensible defaults, and maintaining old endpoints while adding new ones.
Fourth, I implement API version negotiation for custom services—allowing clients to request specific versions through headers or URL parameters. Fifth, I maintain comprehensive documentation of API contracts including expected inputs, outputs, error codes, and behavior.
Sixth, I deprecate old versions gracefully—announcing deprecation with long lead times, continuing to support during transition periods, and providing migration guides. For custom Apex REST services, I version using URL paths like /services/apexrest/myapi/v1 versus /services/apexrest/myapi/v2, keeping separate classes for each version.
This explicit versioning enables independent evolution of each version. When consuming external APIs, I monitor their versioning policies, subscribe to deprecation announcements, and schedule regular updates to keep integrations current. Proactive version management prevents the crisis of discovering deprecated APIs have shut down.
Preparing for Your Integration Interview
Research the Organization's Integration Landscape
Before your interview, investigate the company’s technology ecosystem. Look for mentions of specific tools, systems, or platforms in job descriptions. Understanding whether they use Salesforce alongside SAP, Microsoft Dynamics, Oracle, or specific industry applications helps you frame answers relevantly. Review their product offerings—B2B versus B2C companies have different integration patterns.
Build a Portfolio of Integration Examples
Create sample integrations showcasing different scenarios: REST and SOAP callouts, inbound and outbound patterns, event-driven architectures, and error handling. Being able to reference specific code samples or architecture diagrams during interviews demonstrates hands-on expertise beyond theoretical knowledge.
Practice Explaining Complex Concepts Simply
Integration discussions can become highly technical quickly. Practice explaining complex patterns, protocols, and architectures in simple terms that non-technical stakeholders could understand. This skill is invaluable—integration architects frequently communicate with business leaders making technology decisions.
Stay Current with Salesforce Releases
Salesforce releases three times annually, often adding integration capabilities. Familiarize yourself with recent enhancements like new API versions, Composite API improvements, or Platform Event features. Mentioning recent capabilities shows you’re actively engaged with platform evolution.
Prepare Scenario-Based Responses
Think through how you’d approach common integration scenarios: customer data synchronization, order processing automation, real-time inventory updates, payment gateway integration. Having mental frameworks for these scenarios enables confident responses to scenario-based questions.
Common Interview Pitfalls to Avoid
Over-Engineering Solutions:Â Don’t propose complex architectures when simpler approaches suffice. Interviewers value pragmatic solutions that balance sophistication with maintainability and cost.
Ignoring Non-Functional Requirements:Â Discussing only the happy path without addressing error handling, security, performance, and monitoring shows incomplete thinking. Production integrations require comprehensive consideration of all operational aspects.
Â
Failing to Ask Clarifying Questions:Â When presented with scenarios, don’t make assumptions. Ask about data volumes, real-time versus batch requirements, existing systems, security constraints, and business criticality just as you would in real projects.
Speaking in Jargon Without Explanation:Â Using technical terminology without ensuring the interviewer follows your explanation can backfire. Explain concepts clearly, checking for understanding before proceeding to the next topic.
Lacking Real-World Examples:Â Theoretical knowledge without practical application raises concerns. Whenever possible, reference actual projects, challenges you’ve encountered, and how you resolved them.
Not Demonstrating Business Value: Technical integration details matter, but interviewers also want to know you understand how integrations deliver business value—improving efficiency, enabling new capabilities, reducing costs, or improving customer experience.
Real-World Integration Scenarios
During interviews, you might be asked to design solutions for these common scenarios:
E-Commerce Integration:Â
Synchronizing order data from Shopify or Magento into Salesforce Opportunities and Orders, updating inventory across systems, and providing customer service teams unified views.
Marketing Automation Sync:Â
Bidirectional data flow between Salesforce and Marketo or HubSpot, ensuring lead scoring updates in real-time and campaign responses flow back to Salesforce.
Financial System Integration:Â
Creating invoices in NetSuite or QuickBooks when Opportunities close, synchronizing payment status, and reconciling financial data.
Telephony Integration:Â
CTI integration enabling screen pops with customer information when calls arrive, logging call activities automatically, and click-to-dial from Salesforce.
Document Management:Â
Integrating Salesforce with SharePoint or Box for document storage while maintaining associations with Salesforce records.
Mobile Application Backend:Â
Building custom REST APIs that mobile apps consume for offline-first capabilities and real-time data synchronization.
Being able to articulate your approach to these scenarios, including architectural decisions, technology choices, and implementation considerations, demonstrates real-world readiness.
Advanced Architectural Topics
For senior integration roles, be prepared to discuss advanced topics like microservices architectures with Salesforce as one service among many, event-driven architectures using Kafka or RabbitMQ with Salesforce, API management strategies including rate limiting and monetization, data governance including master data management and data quality, compliance requirements like GDPR or HIPAA affecting integration design, disaster recovery and business continuity for mission-critical integrations, and DevOps practices for integration development including CI/CD pipelines and automated testing.
These advanced topics separate senior architects from developers. Demonstrating understanding of enterprise-scale considerations, architectural trade-offs, and strategic technology decisions positions you for leadership roles.
Taking Your Integration Skills Further
Mastering integration interview questions is just the beginning. True expertise comes from hands-on implementation, learning from failures, and continuously expanding your knowledge as both Salesforce and integration technologies evolve.
Ready to Become an Integration Expert?
If you’re serious about mastering Salesforce integration and want to build the practical skills that interviews actually test, consider investing in comprehensive training. Our Salesforce Integration with External Systems course will take your Integration Skills to Next Level.Â
Don’t just prepare for interviews—build the comprehensive integration expertise that makes you the candidate companies actively recruit. The course covers everything from foundational concepts to advanced architectural patterns, ensuring you can confidently tackle any integration challenge.
Final Thoughts
Salesforce integration expertise opens doors to some of the most challenging and rewarding roles in the Salesforce ecosystem. Organizations increasingly recognize that connecting Salesforce with their broader technology landscape creates exponentially more value than isolated implementations.
The interview questions covered in this guide represent the spectrum of what you’ll encounter—from fundamental concepts to advanced architectural decisions. But remember that interviewers aren’t just testing your knowledge—they’re evaluating your problem-solving approach, communication skills, and ability to balance technical possibilities with business requirements.
Successful integration professionals combine technical depth with business acumen, architectural vision with practical implementation skills, and confident expertise with humble willingness to learn. They understand that every integration is unique, requiring thoughtful analysis rather than cookie-cutter solutions.
As you prepare for interviews, focus on understanding the “why” behind each integration pattern and technology choice, not just the “how.” Be ready to explain trade-offs, discuss alternatives, and justify your recommendations. Practice explaining complex concepts simply. Build real integrations to solidify understanding beyond theory.
The demand for integration expertise continues growing as organizations pursue digital transformation initiatives that depend on seamlessly connected systems. With thorough preparation, hands-on experience, and the confidence that comes from genuine understanding, you’re well-positioned to succeed in your next integration interview and thrive in your integration career.
Good luck with your interview preparation, and may your integration journey be filled with elegant solutions and successful implementations!
