Integration Architect Interview Questions

REST (Representational State Transfer) is stateless — every request contains all information needed to process it. It uses standard HTTP verbs (GET, POST, PUT, PATCH, DELETE) and typically exchanges JSON, making it lightweight and easy to consume by modern web and mobile clients. SOAP (Simple Object Access Protocol) is stateful-capable, uses XML exclusively, and relies on a WSDL (Web Services Description Language) contract to define the interface.

Choose REST when: you need lightweight, high-performance integrations with web/mobile apps, the external system supports JSON, or you want simple URL-based endpoints. Choose SOAP when: you need built-in WS-Security, ACID transactions, or must integrate with legacy enterprise systems that expose only WSDL-based services. Salesforce exposes both: the REST API (JSON/XML) and the SOAP API (WSDL-based). Most modern integrations prefer REST.

1. Web Server Flow: Best for server-side web apps. The app redirects to Salesforce login, the user authenticates, and Salesforce returns an authorization code. The server exchanges the code for an access token. Credentials never exposed to the browser. Most secure for interactive server apps.

2. User-Agent Flow: For client-side JavaScript apps. Access token is returned in the URL fragment — never sent to the server. Risk: token is exposed in browser history and referrer headers. Use with caution.

3. JWT Bearer Token Flow: Server-to-server, no user interaction. The app signs a JWT with a private key; Salesforce validates via the registered Connected App certificate and issues an access token. Ideal for automated integrations and Apex callouts requiring named credentials.

4. Username-Password Flow: App sends username + password + security token directly to Salesforce. No redirect. Highest risk — credentials embedded in app. Avoid in production; use only for trusted internal automation where other flows are not feasible.

Remote Site Settings simply whitelist an external URL, allowing Apex callouts to that domain. They provide no credential management — authentication must be handled manually in code (headers, tokens, etc.).

Named Credentials are a more secure and powerful mechanism. They store the endpoint URL, authentication protocol (No Auth, Password, OAuth, AWS Signature V4, JWT), and credentials encrypted in Salesforce metadata. In Apex, you reference them as callout:MyCredential/path. Salesforce automatically attaches the authentication header at runtime — credentials never appear in code.

Named Credentials also support per-user authentication: each Salesforce user can have their own OAuth token stored under a Named Credential (via External Credentials in Winter '23+). This enables user-context API calls rather than a shared service account. Remote Site Settings do not support credential management at all.

A Connected App is a framework that enables external applications to integrate with Salesforce via OAuth 2.0. Key settings include:

IP Relaxation: Controls whether login IP restrictions are enforced for the Connected App. "Relax IP Restrictions" lets users authenticate from any IP, while "Enforce IP Restrictions" blocks access from outside trusted IP ranges. Over-relaxing creates security risk.

Refresh Token Policy: Controls the lifetime of refresh tokens — can be set to expire immediately, after a defined period, or never. Long-lived refresh tokens increase risk if compromised.

OAuth Scopes: Limit what the Connected App can access (api, refresh_token, web, full, chatter_api, etc.). Follow least-privilege — grant only the scopes required.

Callback URL: The authorized redirect URI for the Web Server flow. Must exactly match what the app sends.

Session Policies: Enforce MFA or specific session security levels for the integration.

Salesforce Connect allows Salesforce to display and interact with data stored in external systems in real time, without copying data into Salesforce. Data appears as External Objects (suffix __x) and can be related to standard/custom objects via External Lookups and Indirect Lookups.

OData 2.0 Adapter: Older standard. Supports basic CRUD. Good for legacy systems that expose OData 2.0 endpoints. Limited to Atom/XML format.

OData 4.0 Adapter: Newer standard with JSON support, better performance, server-side pagination, and more operators. Preferred for new integrations.

Cross-Org Adapter: Connects two Salesforce orgs so one org can read/write data in another org's objects as External Objects. Uses OAuth to authenticate between orgs. Useful for multi-org architectures where data must remain in a secondary org but be visible in the primary.

Heroku Connect: Bi-directional sync (not real-time query) between Salesforce and a Heroku PostgreSQL database, using a polling or streaming mechanism.

Platform Events implement the publish-subscribe pattern. Publishers fire events using DML (EventBus.publish()) or Apex; subscribers listen via Apex triggers on the event, Flows, or CometD (streaming API for external systems).

Replay ID: Every published event is assigned a monotonically increasing Replay ID. Subscribers store the last-processed Replay ID and use it to replay missed events. Replay ID -1 retrieves the most recent event; -2 retrieves all events stored in the 72-hour retention window.

Gap Events: When a subscriber falls behind and events are delivered out of order or with gaps (e.g., due to connection drops), the subscriber can use the stored Replay ID to reprocess events from that point. An event gap occurs when the subscriber receives a Replay ID higher than the next expected — indicating missed events. The subscriber should replay from the last known good Replay ID.

Publish-After-Commit: Platform Events published within a transaction are only delivered to subscribers after the transaction commits. If the transaction rolls back, the events are not delivered — ensuring consistency.

Platform Events are custom event messages published by your code. You define the schema and decide when to publish. They are best for application-level events and decoupling services.

Change Data Capture (CDC) automatically generates change events whenever a Salesforce record is created, updated, deleted, or undeleted — without any custom code. CDC events contain:
- Enriched fields: The changed fields and their new values, plus header metadata (changeType: CREATE/UPDATE/DELETE/UNDELETE, changedFields bitmap, recordId, commitTimestamp).
- Gap Events: When the CDC subscriber has been offline, Salesforce may issue a gap event indicating missed events, so the subscriber knows to do a full re-sync for affected records.

Key difference: CDC is declarative and Salesforce-generated (enabled per object in Setup); Platform Events are custom and code-driven. CDC is ideal for replicating Salesforce data to external systems; Platform Events are ideal for custom integration workflows.

Outbound Messaging sends a SOAP XML message to an external endpoint when a record meets workflow criteria (triggered via Workflow Rules or Approval Processes). Salesforce generates a WSDL that the receiving endpoint must implement to accept the message.

Delivery Guarantee: Outbound Messaging provides at-least-once delivery. If the endpoint does not return an acknowledgment (ACK) within the timeout period, Salesforce retries with exponential back-off for up to 24 hours. The receiving endpoint must handle duplicate messages idempotently.

Acknowledgment: The endpoint must return a specific SOAP response containing <Ack>true</Ack>. Without this ACK, Salesforce will keep retrying.

Limitations: Outbound Messaging is SOAP-only, limited to workflow-triggered contexts, and does not support REST or JSON. For modern integrations, Platform Events or CDC are preferred over Outbound Messaging.

REST API: Best for real-time, record-level CRUD operations — up to 200 records per composite request. JSON or XML. Synchronous response. Use for interactive integrations, UI-driven operations, and low-volume data exchange.

Bulk API 2.0: Designed for large-volume data operations (hundreds of thousands to millions of records). Uses CSV format. Operations are asynchronous — you submit a job, upload CSV data, close the job, and poll for completion.

Job States: Open → UploadComplete → InProgress → JobComplete / Failed / Aborted.

Concurrency Mode: Bulk API 2.0 uses serial processing by default (only one batch per job runs at a time, reducing database contention). Bulk API 1.0 offered parallel mode (multiple batches concurrently) but risked record lock conflicts. Bulk API 2.0 removed the parallel option to improve reliability.

Use Bulk API 2.0 for data migrations, nightly ETL loads, and mass updates. Use REST API for real-time integrations with low record counts.

The Composite API family allows multiple REST API calls in a single HTTP request, reducing round trips:

Composite Request: Execute up to 25 sub-requests sequentially. Each sub-request can reference the response of a previous one using @{referenceId}. Supports mixed object types. All requests share one governor limit context. If one fails and allOrNone: true, all are rolled back.

sObject Tree: Create up to 5 parent records and their related children (up to 200 records total) in one call. Ideal for inserting a hierarchy (e.g., Account + Contacts + Opportunities) atomically.

Composite Batch: Execute up to 25 independent sub-requests. Requests do NOT share context — each is processed independently. No cross-referencing between requests. Failures do not roll back others.

Composite Graph: Execute multiple independent composite graphs in one request. Graphs within a request are independent; sub-requests within a graph can cross-reference each other. More powerful than composite request for complex dependency trees.

Synchronous callout limits: 100 HTTP callouts per transaction, 10 seconds per callout timeout (configurable up to 120 seconds), 6 MB response body per callout, 12 MB total heap. Callouts cannot be made after DML in the same synchronous context (without using mixed-DML patterns).

Async workarounds:
1. Queueable Apex: Enqueue a Queueable job from a trigger (after DML) to perform the callout asynchronously. Queueable jobs allow callouts and can be chained.
2. @future(callout=true): Simple async callout method. Cannot accept non-primitive parameters.
3. Batch Apex: Use Database.AllowsCallouts interface to make callouts in the execute() method (one callout per batch chunk).

Best practice: For high-volume callouts, use Queueable chaining or Platform Events to trigger an external worker, rather than making hundreds of synchronous callouts.

Implementation: Use HttpRequest and HttpResponse classes with an Http instance:
Http h = new Http(); HttpRequest req = new HttpRequest(); req.setEndpoint('callout:MyNC/api/v1/resource'); req.setMethod('POST'); req.setHeader('Content-Type', 'application/json'); req.setBody(JSON.serialize(payload)); req.setTimeout(20000); HttpResponse res = h.send(req); if(res.getStatusCode() == 200) { ... }

Testing: Salesforce does not make real callouts in tests. Implement the HttpCalloutMock interface and register it with Test.setMock(HttpCalloutMock.class, new MyMock()). The mock returns a predefined HttpResponse. Use MultiStaticResourceCalloutMock for multi-callout tests.

Timeout: req.setTimeout() accepts milliseconds (1000–120000). Always set a timeout to avoid transactions hanging indefinitely.

Always test both success and error response codes, and verify idempotent retry logic.

Idempotency: An operation is idempotent if performing it multiple times produces the same result as performing it once. For integrations, use idempotency keys (a unique transaction ID included in each request). The receiving system uses this key to detect and ignore duplicate requests. This is critical when retries may cause duplicate records or payments.

Retry with Exponential Backoff: On transient failures (HTTP 429, 503, 504), retry the request with increasing wait intervals (e.g., 1s, 2s, 4s, 8s…) plus random jitter to prevent thundering herd. Cap the maximum retry count and total wait time. In Salesforce, implement via Queueable chaining with a retry counter stored in the job state.

Circuit Breaker Pattern: Prevents cascading failures by "opening" the circuit after a threshold of consecutive failures. In OPEN state, requests fail fast without attempting the external call. After a cooldown period, the circuit moves to HALF-OPEN — one test request is allowed. If it succeeds, the circuit closes. Implement in Salesforce using Custom Metadata or Cache to track failure counts and circuit state.

API versioning ensures that changes to an API do not break existing consumers.

URL Path Versioning: Version number embedded in the URL (e.g., /api/v1/accounts, /api/v2/accounts). Salesforce's own REST API uses this approach (/services/data/v59.0/). Pros: Highly visible, easy to test in a browser, simple to route at the gateway. Cons: URLs proliferate, and technically violates REST principles (the same resource shouldn't have different URLs by version).

Header Versioning: Version specified in a custom request header (e.g., API-Version: 2). Pros: Cleaner URLs, aligns with REST principles. Cons: Harder to test/debug, invisible in browser URL bar, requires client implementation discipline.

Salesforce recommendation: Use URL path versioning for external APIs (matching Salesforce's own pattern). Always maintain backward compatibility for at least 2–3 major versions before deprecation. Document breaking changes clearly.

Request-Response (Synchronous): The caller sends a request and waits for an immediate response. Simple, predictable, easy to debug. Best for operations requiring immediate confirmation (e.g., payment authorization, real-time data retrieval). Drawback: Tight coupling — if the downstream service is slow or unavailable, the caller is blocked. Governor limits are consumed while waiting.

Event-Driven (Asynchronous): The publisher fires an event and continues without waiting. Subscribers process events independently. Pros: Loose coupling, resilience to downstream failures, natural scalability, supports fan-out (multiple subscribers to one event). Cons: Harder to debug (no immediate feedback), eventual consistency, need to handle duplicate events and ordering guarantees.

In Salesforce: Use Platform Events or CDC for event-driven patterns. Use synchronous REST API for real-time request-response. A hybrid approach is common — synchronous for user-facing operations, event-driven for back-office processing and integrations.

Heroku Connect provides bi-directional data synchronization between Salesforce and a Heroku PostgreSQL database. It is used to expose Salesforce data to Heroku apps without repeated API calls.

Polling mode (Salesforce → Heroku): Heroku Connect polls Salesforce using the REST API (SOQL queries with SystemModstamp filters) to detect changes. Simple but introduces latency. Suitable for non-real-time sync needs.

Streaming/Push mode: Heroku Connect uses the Salesforce Streaming API (CometD / CDC) to receive real-time change notifications, reducing latency significantly. More complex to configure but much more responsive.

Write Mode (Heroku → Salesforce): Changes made to the PostgreSQL table can be written back to Salesforce. Heroku Connect monitors rows with a trigger for changes and uses the Salesforce REST API to upsert them. System of Record determines which side wins on conflict — Salesforce or Heroku Postgres. Over-writing from Heroku without proper conflict handling can cause data loss.

Point-to-point integration: Direct connection between two systems (e.g., Salesforce → SAP via Apex callout). Simple and fast for small numbers of integrations. As the number of systems grows, complexity becomes unmanageable (n*(n-1)/2 connections for n systems) — the "spaghetti integration" problem.

MuleSoft (iPaaS / API-led connectivity): An integration platform that provides a central hub for connecting systems. Benefits: Reusable APIs (System → Process → Experience layer), centralised monitoring and error handling, pre-built connectors for 300+ systems, governance and rate limiting, transformation with DataWeave. Best for enterprises with many systems (ERP, CRM, HRIS, commerce) that share data.

Choose MuleSoft when: You have 5+ systems to integrate, need reusable APIs across teams, require centralised logging/monitoring, or need complex data transformations. Choose point-to-point when: The integration is simple, involves only 2 systems, has low complexity, and the overhead of a full iPaaS is unjustified.

SAML SSO (Security Assertion Markup Language) allows users to authenticate with an Identity Provider (IdP) and access Salesforce without re-entering credentials.

Configuration steps: (1) In Salesforce, navigate to Single Sign-On Settings and enable SAML. (2) Create an SSO configuration with the IdP's Issuer URL, IdP certificate (uploaded to Salesforce), and the Login URL. (3) The IdP is configured with Salesforce's Audience URL (Entity ID) and ACS (Assertion Consumer Service) URL.

Key SAML Assertion components:
- Issuer: The IdP's unique identifier.
- Subject (NameID): The user identifier (Salesforce username or Federation ID).
- Audience: Must match Salesforce's Entity ID.
- Conditions: Time bounds (NotBefore, NotOnOrAfter) to prevent replay attacks.
- Signature: The IdP digitally signs the assertion using its private key; Salesforce verifies using the uploaded certificate.
- Relay State: Optional parameter that tells Salesforce where to redirect the user after successful authentication (deep link).

The JWT Bearer Token Flow allows a server app to authenticate to Salesforce without user interaction:

Setup: (1) Generate an RSA key pair (private key for the app, certificate/public key uploaded to the Connected App in Salesforce). (2) In the Connected App, enable "Use Digital Signatures". (3) Pre-authorize the integration user by either having them approve the app once, or enabling "Admin Approved Users Only" and adding the user profile/permission set.

Runtime flow: (1) The app creates a JWT with claims: iss (Consumer Key of Connected App), sub (Salesforce username), aud (Salesforce token endpoint), exp (expiry, max 3 minutes). (2) The app signs the JWT with its private key. (3) The app POSTs to https://login.salesforce.com/services/oauth2/token with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<JWT>. (4) Salesforce validates the JWT signature using the stored certificate and returns an access_token. (5) The app uses the access token for API calls. No refresh token is issued — a new JWT must be requested when the token expires.

An API Gateway sits between external consumers and backend APIs, providing a single entry point with centralised capabilities:

Patterns in Salesforce context:
- Salesforce as the gateway: Salesforce Experience Cloud APIs (Community endpoints) or Salesforce API Management (limited). External systems call Salesforce as their primary integration point.
- MuleSoft API Gateway: MuleSoft Anypoint Platform acts as a full gateway — routing, rate limiting, authentication (OAuth policy), IP whitelisting, caching, and analytics. Salesforce is one of the downstream systems.
- AWS API Gateway / Azure APIM: Cloud-native gateways that front Salesforce APIs. Used when Salesforce is part of a broader cloud architecture.

Key gateway capabilities: Rate limiting (throttle per consumer), authentication enforcement (JWT/API key validation before reaching Salesforce), request/response transformation, caching to reduce Salesforce API calls, logging and analytics, canary routing for API version migrations.

Streaming API (CometD / Platform Events / CDC): Real-time push of individual record changes or custom events to subscribed clients. Events are pushed as they occur, typically within seconds. Best for: real-time dashboards, instant notifications to external systems, triggering downstream workflows as soon as data changes. Limitations: 72-hour event retention, subscriber must manage Replay IDs, not suitable for initial full data loads or historical backfills.

Bulk Data Sync (Bulk API, scheduled SOQL export, ETL): Periodic batch extraction of large datasets. Use for: initial data loads into data warehouses, nightly sync to downstream systems, historical data backfills, data archiving. Tolerates latency (minutes to hours) in exchange for high throughput.

Hybrid approach: Use Bulk API for the initial full load (historical data), then switch to CDC/Streaming API for ongoing delta changes. This is the recommended pattern for data warehouse integrations (e.g., Salesforce → Snowflake via MuleSoft or a Salesforce change data capture listener).

1. Apex: Full programmatic control. Use for complex transformations, conditional logic, and when transformation is tightly coupled with Salesforce business logic. Most flexible but requires code maintenance and consumes Apex governor limits.

2. DataWeave (MuleSoft): A functional language specifically designed for data transformation. Supports JSON, XML, CSV, Java, and more. Powerful pattern matching and type-safe transformations. Best for middleware-layer transformations when MuleSoft is in the architecture.

3. Flow (Data Transformation elements): Declarative transformations within Flow Builder — field mapping, data type conversion. Suitable for simple field-to-field mapping without middleware.

4. External ETL tools (Informatica, Talend, dbt): Dedicated transformation engines for heavy data processing before or after Salesforce. Best for complex multi-system data reconciliation.

Architectural principle: Keep transformation close to where the data is produced or consumed (canonical data model approach). Avoid repeated transformation across multiple hops, which creates maintenance overhead.

Outbound Webhook (Salesforce → External): Salesforce pushes data to an external HTTP endpoint when a record event occurs. Implementation options:
- Outbound Messaging: SOAP-based, workflow-triggered. Good for guaranteed delivery but SOAP-only.
- Apex Trigger + Queueable callout: Flexible REST-based outbound call. Can use Named Credentials. Must handle retry and error logging.
- Platform Event → External subscriber: External system subscribes via CometD or MuleSoft. Decoupled and scalable.

Inbound Webhook (External → Salesforce): An external system pushes data into Salesforce. Implementation options:
- Salesforce REST API: External system calls the standard REST API to create/update records. Requires OAuth authentication.
- Apex REST (@RestResource): Custom endpoint exposing business-logic-aware entry points (e.g., /services/apexrest/orders/). Ideal for complex inbound processing.
- Experience Cloud API endpoint: For partner-facing ingestion without full Salesforce credentials.

Always validate incoming payloads, authenticate callers, and handle idempotency on inbound webhooks.

The Analytics External Data API (also called the Insights External Data API) allows you to upload external data into Tableau CRM (Einstein Analytics) datasets from outside Salesforce.

Ingestion flow: (1) Create an InsightsExternalData record specifying the target dataset, format (CSV), operation (Overwrite/Append/Upsert/Delete), and attach the JSON schema (metadata file). (2) Upload data in parts as InsightsExternalDataPart records (each part up to 10 MB, total dataset up to ~40 GB). (3) Set InsightsExternalData.Action to "Process" to trigger the dataflow. (4) Monitor the Status field (Queued → InProgress → Completed/Failed).

Use cases: Loading data from external systems (ERP, marketing platforms) into Tableau CRM for unified analytics dashboards. External data appears alongside native Salesforce data in Analytics datasets.

Alternative — Direct Data API: Einstein Analytics also supports a newer Direct Data connection via Salesforce Connect or external data sources natively. For programmatic ingestion, the External Data API remains the primary method.

A resilient high-volume Salesforce-to-ERP integration requires addressing several architectural concerns:

Decoupling: Use Platform Events or a message queue (MuleSoft, AWS SQS) between Salesforce and the ERP. Salesforce publishes events; the ERP consumer processes at its own pace. This prevents Salesforce governor limits from being blocked by slow ERP responses.

Idempotency: Assign a unique transaction ID to every message. The ERP ignores duplicates based on this ID — critical when retries occur.

Error handling: Implement a dead-letter queue for failed messages. Route to a monitoring/alerting system (e.g., Slack, PagerDuty). Store failed records in a Salesforce custom object for manual review and replay.

Batching: Aggregate individual Salesforce record changes into micro-batches before calling the ERP if the ERP has per-call overhead. Use Schedulable Apex or a Queueable chain to bundle records.

Circuit breaker: Detect ERP unavailability using failure thresholds stored in Custom Metadata. Stop sending during ERP downtime; backfill via replay when restored.

Monitoring: Log every integration transaction (request, response, status, timestamp) to a custom object or external logging platform. Set up Salesforce reports/dashboards for integration health metrics.