Integrations Basic Interview Questions

• It means connecting Salesforce with other systems.
• Helps in sharing data or triggering processes.
• Can be real-time or batch-based.
• Uses APIs, events, or middleware to communicate.

• To avoid manual data entry across systems.
• To keep data consistent across platforms (e.g., CRM + ERP).
• To automate workflows across business apps.
• To enable real-time decisions using combined data.

• Data Integration – sync or migrate data (via APIs, ETL tools).
• Process Integration – trigger actions across systems (e.g., callouts, platform events).
• UI Integration – embed external systems into Salesforce UI (e.g., iframe).
• Security Integration – enable SSO, OAuth between systems.

🔸 Inbound Integration (External System → Salesforce)

• External system sends data into Salesforce.
• Uses Salesforce REST API or SOAP API to receive requests.
• Requires OAuth token or session ID for authentication.

  Example: A website form pushes new Lead data to Salesforce.

🔹 Outbound Integration (Salesforce → External System)

• Salesforce sends data to an external system.
• Uses Apex callouts, Flows, or Outbound Messages.
• Can be synchronous (Apex callout) or asynchronous (Platform Event, Future/Queueable). 

       Example: Salesforce sends order info to a shipping API.

• API = Application Programming Interface.
• A set of rules for software to talk to each other.
• Salesforce offers REST, SOAP, Bulk, Streaming APIs.
• APIs allow data exchange and automation between Salesforce and other systems.

🔸 REST API

• Uses JSON format (lightweight and human-readable).
• Easy to set up and faster for most use cases.
• Best for web apps, mobile apps, and lightweight integrations.
• Stateless and flexible with standard HTTP methods (GET, POST, etc.).

Example: Create a Lead using Postman via REST.

🔹 SOAP API

• Uses XML format (heavier and more structured).
• More secure and standardized, good for enterprise systems.
• Best for legacy systems and strict data contracts.
• Requires WSDL for setup and follows rigid schemas.

Example: ERP system pushes data to Salesforce using SOAP.

• When you need to insert, update, or delete a large number of records.
• Good for data migration or batch processing.
• Works in batches and is more efficient than REST/SOAP.

        Example: Importing 100,000 contacts at once.

• Used to get real-time updates from Salesforce.
• No need to keep checking (polling) — it pushes changes to clients.
• Works well for notifications or live dashboards.

        Example: Alert an app when a Case is updated.

• Used by developers or tools (like VS Code, Developer Console).
• Helps manage metadata, Apex classes, triggers, etc.
• Also used by apps like Salesforce CLI and LWC tools.

        Example: Get Apex class info from an IDE.

• Newer API that lets you get only the data you need.
• Faster and more efficient than REST in some cases.
• Combines multiple queries in one call (no over-fetching).

        Example: Get Account + Contacts in a single request.

• OAuth 2.0 – most common, secure, and modern.
• Username-Password flow – simple but less secure.
• JWT (JSON Web Token) flow – used for server-to-server integration.
• SAML – for Single Sign-On (SSO).
• Session ID – legacy, not recommended for new apps.

• OAuth 2.0 is a secure way to access Salesforce without storing passwords.
• It uses access tokens to call APIs.
• You register a Connected App in Salesforce to enable OAuth.
• Common in apps like Postman, web servers, mobile apps.

🔸 Username-Password OAuth Flow

• Sends username + password directly with client ID and secret.
• Simple to implement, but less secure.
• No user interaction (good for scripts or testing).
•  Not recommended for production due to password exposure risk.

🔹 JWT OAuth Flow (JSON Web Token)

• Sends a signed token using a digital certificate (no password).
• More secure, ideal for server-to-server integrations.
• Works well in headless, background, or scheduled jobs.
• Requires setting up a Connected App with certificate.

• Set "Access + Refresh Token" in Connected App scopes.
• During the first login, the response includes a refresh token.
• Store this token securely.
• Use it to get a new access token without re-login.

• Use Named Credentials in Salesforce (preferred).
• Or store in encrypted custom metadata or secure server vaults.
• Avoid hardcoding usernames or passwords.
• Use OAuth tokens, encryption, and IP whitelisting for safety.

• Use Apex HTTP methods: HttpRequest, Http, HttpResponse.
• Set the API endpoint URL, headers, and body.
• Make the callout in a class or method with @future(callout=true) if needed.

         Example: Send a POST request to an external payment system

• A secure way to store API endpoints and authentication in Salesforce.
• Replaces hardcoding usernames, passwords, or tokens in Apex.
• Makes callouts easier and more secure.

         Example: Store the URL and auth for an external weather API.

• Use try...catch blocks to catch callout errors.
• Check the status code and response body for failure messages.
• Log errors in a custom object or send alerts.
• Always handle timeouts, authentication errors, and 5xx responses gracefully.

 From Trigger

• Not allowed directly (synchronous callouts are blocked).
• You must use a Future method, Queueable Apex, or Batch Apex to make the callout.
• Triggers must run fast — no waiting for external responses.
• You can also publish a Platform Event and process it asynchronously.

🔹 From Flow

• Allowed using External Services, Apex-Defined Actions, or HTTP Callout (in Flow Builder with API version 59+).
• More flexible for low-code outbound integrations.
• Can be combined with Scheduled Paths or Platform Events.
• Easier for admins and no-code users to configure.

• Write a class implementing Schedulable and call your callout method.
• Mark the callout method as @future(callout=true) or use Queueable Apex.
• Schedule using Apex Scheduler or via UI (Setup → Apex Classes → Schedule).

         Example: Daily call to sync product prices from an external system.

• By using Salesforce APIs like REST API or SOAP API.
• The external system sends data using POST (create) or PATCH (update).
• It needs a valid access token (OAuth) to connect securely.
• Example: A website form sends contact data into Salesforce via REST API.

• Use @RestResource annotation to create a custom REST endpoint.
• Use webService keyword for SOAP web service methods.
• Make sure the class is marked as global or public.

        Example: A custom REST API that inserts Leads from a mobile app.

🔸 @RestResource

• Used to create custom REST API endpoints in Apex.
• Called by external systems (outside Salesforce).
• Requires OAuth authentication (access token).
• Works with tools like Postman, external apps, middleware.

🔹 @AuraEnabled

• Used to expose Apex methods to Lightning Components (LWC/Aura).
• Called by client-side JavaScript within Salesforce UI.
• Works only for logged-in users (inside org context).
• Used in Lightning Web Components, Aura, and Flows.

• Use OAuth 2.0 authentication (via Connected App).
• Set IP Whitelisting and permission sets for integration users.
• Use Named Credentials when possible.
• Always validate input to avoid data injection or misuse.

• Use tools like Postman to send test API calls.
• Check Debug Logs, API usage logs, or Event Monitoring in Salesforce.
• Use System.debug() in Apex to log request data.
• Monitor with Integration logs (custom object) for deeper tracking.

• Remote Process Invocation – Salesforce triggers an external system.
• Remote Call-In – External system calls Salesforce to take action.
• Data Synchronization – Keep data in sync between Salesforce and other systems.
• UI Update Based on Data Changes – Live updates using Streaming/Platform Events.
• These patterns help choose the right integration method based on use case.

🔸 Remote Process Invocation

• Used to trigger actions in an external system from Salesforce.
• Example: Call a shipping API when an Order is confirmed.
• Typically real-time using Apex callouts or Platform Events.
• Best when you want to initiate a process, not just share data.

🔹 Data Synchronization

• Used to keep data consistent across multiple systems.

        Example: Sync customer records from ERP to Salesforce.

• Usually done in batches or at scheduled intervals.
• Ideal for bi-directional data exchange (e.g., customer or product sync).

Platform Events

• Used to define custom events in Salesforce.
• Ideal for app-to-app communication or microservices architecture.
• Supports replay, durable messaging, and custom payloads.
• Can be published and subscribed using Apex, Flows, or external systems.

🔹 Streaming API

• Used to track changes on Salesforce records (like Account, Contact, etc.).
• Best for real-time notifications on object changes.
• Supports Change Data Capture (CDC) and PushTopics.
• Has limited filtering and no replay buffer (unless using CDC with replay IDs).

• Connects Salesforce with other systems and handles data transformation.
• Manages authentication, retries, logging, error handling.
• Useful in complex, multi-system integrations.

        Example: Mulesoft connects Salesforce with SAP, Oracle, etc.

• Use Bulk API or Batch Apex for large data.
• Apply filters, pagination, and data compression.
• Use caching or queuing for non-urgent updates.
• Always monitor governor limits and API call usage.

• Use try–catch blocks to catch exceptions during callouts.
• Log the error using custom objects, debug logs, or Platform Events.
• Check the HTTP response status to handle API-specific errors.
• Optionally, notify users/admins with email or in-app alerts.

• n Flows: use Scheduled Path or Wait element with a counter variable.
• In Apex: use @future, Queueable, or Batch jobs with logic to retry on failure.
• Add a custom retry flag or attempt count field to prevent infinite loops.
• Consider exponential backoff (increasing wait times after each failure).

• DLQ stores events that fail to process after multiple tries.
• Helps in identifying and reviewing problematic or corrupted events.
• Ensures good events are not blocked by failed ones.
• Salesforce supports DLQ for Platform Events and CDC (Change Data Capture).

• Set up Email Alerts, Custom Notifications, or Platform Events.
• Use tools like Event Monitoring, Debug Logs, or Flow Error Logs.
• Track API errors using Monitoring tools, or build a custom error dashboard.
• Integration middleware (like Mulesoft) can also trigger alerts.

• Create a custom Logging object to store error details.
• Include fields like timestamp, status, error message, retry count.
• Use System.debug(), Database.SaveResult, or Messaging.SendEmail.
• Always log in Queueable, Future, and Batch Apex for post-analysis.

• Mulesoft is an integration platform that connects apps, data, and devices.
• It allows Salesforce to communicate with external systems (like SAP, Oracle).
• Uses APIs, connectors, and flows to move and transform data.
• Supports real-time, batch, and event-driven integrations.

• Yes — Postman is a tool to test and debug APIs.
• You can send GET, POST, PATCH, DELETE requests to Salesforce APIs.
• Requires setting access token (OAuth 2.0) in headers.
• Great for checking if integration endpoints work as expected.

• A feature that lets you use external APIs inside Flows without writing code.
• You import an OpenAPI (Swagger) specification.
• It creates invocable actions available in Flow Builder.
• Good for low-code integrations like payment, shipping, or chat APIs.

• Platform Events are used to send and receive real-time messages.
• Salesforce can publish or subscribe to these events.
• Useful for loosely coupled systems (like notifying an ERP after order creation).
• Can be used in Flows, Apex, or external systems (via CometD).

• Lets you view external data in Salesforce without storing it.
• Uses External Objects linked to data sources (like OData, SAP, SQL).
• Ideal when you need real-time access but don’t want to copy data.

         Example: Show live inventory data from a warehouse system.

• Use middleware like Mulesoft, Dell Boomi, or Informatica to manage data flow.
• Decide on integration type: real-time (API) vs batch (ETL jobs).
• Use Salesforce REST/Bulk API to send/receive data.
• Ensure field mapping, data transformation, and error handling are in place.

• Option 1: Use Web-to-Lead for simple forms (no coding needed).
• Option 2: Use custom web app + REST API to push leads directly.
• Option 3: Use tools like Zapier, Mulesoft, or External Services.
• Secure the API with OAuth 2.0 and IP whitelisting.
• Question: How do you push Salesforce data to a third-party app in real-time?
• Use Apex HTTP callouts from triggers or flows (via Queueable/Future).
• Or use Platform Events to publish messages and let external systems subscribe.
• Use Named Credentials to securely manage endpoints and auth.
• Ensure error handling and retries in case of failures.

• Use Bulk API for large data loads instead of REST.
• Cache responses or use Change Data Capture (CDC) to minimize polling.
• Monitor API usage via Setup → System Overview or Event Monitoring.
• Optimize queries, avoid unnecessary fields, and schedule off-peak hours.

• Use real-time API (REST/Platform Events) for critical updates (e.g., orders).
• Use Batch Apex or scheduled ETL for full syncs or cleanups.
• Middleware can route data differently based on business rules.
• Design with fallbacks (e.g., queue, retry, logging) to handle both modes smoothly.

• Salesforce sets limits to ensure fair resource usage per org.

Key limits:

• Callout timeout: Max 120 seconds per call.
• Concurrent callouts: Max 100 open callouts per transaction.
• API calls per 24 hours: Based on license (e.g., 100,000/day for Enterprise).
• Exceeding limits results in runtime errors or denied API access.

• IP Whitelisting: Restrict login/API access to trusted IP ranges (via Profile or Network Access settings).
• Named Credentials: Securely store API endpoints + authentication (no hardcoded secrets).
• Adds a layer of security and simplifies callout setup.
• Automatically handles OAuth tokens or basic auth.

• Maximum timeout for an Apex callout is 120 seconds (2 minutes).
• Default is often 10 seconds, but it can be set using:
  •  request.setTimeout(120000); // in milliseconds
• Ensure external systems respond within this time to avoid failures.

• Use HTTPS (SSL/TLS) for all integrations — Salesforce requires it.
• Use OAuth 2.0 tokens or JWT for secure, token-based access.
• Shield Platform Encryption encrypts data at rest, not during transmission.
• Avoid sending sensitive data in URL query strings.

• Use retry logic (Apex or middleware) for temporary failures.
• Use load balancing and fallback endpoints in external systems.
• Monitor integrations with logs, alerts, and dashboards.
• Design APIs and jobs to be idempotent (safe to retry without duplicate results).