Integrating External Systems Using Flow HTTP Callouts

Why Integrations are Needed in Salesforce

Salesforce is a powerful CRM platform, but Salesforce alone is never enough in real-world projects. In almost every organization, Salesforce works with multiple external systems. Each system is built for a specific purpose, and Salesforce must communicate with them to complete a business process.

Why Salesforce Cannot Work Alone

Salesforce is mainly responsible for: managing customers, tracking leads and opportunities, storing business data, and automating workflows. However, Salesforce does not usually handle: payments, policy generation, document verification, background business rules, or external reporting engines. Those responsibilities are handled by other specialized systems. To make the business work end‑to‑end, Salesforce must exchange data with these systems – this exchange is called integration.

What Salesforce Integrations Actually Do

1. Send Salesforce Data to Other Systems

Example: send Lead data, Opportunity details, payment or policy information. Salesforce acts as the source system.

2. Receive Data Back into Salesforce

Example: receive policy numbers, payment status, verification results. Salesforce acts as the destination system.

3. Keep Systems in Sync

If data changes in one system, the same change must be reflected in the other (e.g., status updated externally → Salesforce updates its records).

4. Trigger Actions Outside Salesforce

Salesforce can create a policy, initiate a payment, or start background processing in another system using APIs.

Why HTTP-Based Integrations Are Required

HTTP is the most common and standardized way systems communicate today. Salesforce uses HTTP because it is platform‑independent, secure, widely supported, and easy to monitor and debug. Salesforce supports HTTP integrations via Flow HTTP Callouts, Apex Callouts, and Platform Events.

---

Understanding HTTP Basics

HTTP defines how data is sent and received between two systems. Whenever Salesforce integrates with another application, it uses HTTP to send information, request information, and receive results. This communication always follows a request–response model.

Endpoint – API URL

An endpoint is the exact address of the external API. It tells Salesforce which system to contact and which operation to perform. In Flow HTTP Callouts, the endpoint is configured (often via Named Credentials for security and reuse).

HTTP Method – Action Type

• GET – retrieve information (fetch policy status, get verification result). No data is created.
• POST – send data or create something (send Lead, create a policy). Most common in Salesforce integrations.
• PUT – update existing data (modify customer details).
• DELETE – remove data from an external system (cancel a request).

Request – Data Sent from Salesforce

A request includes endpoint, method, headers (authentication, metadata), and body (actual data). In Flow integrations, the request body is usually JSON, mapped from Salesforce fields or Flow variables.

Response – Data Returned by the API

The response contains the result of the operation (IDs, status, messages). In Flow, response values are automatically parsed and can be used in Decisions, Assignments, or Record Updates.

Status Codes – Outcome Indicator

• 200 – Success → continue normal execution.
• 400 – Bad Request → data or validation issue.
• 401 – Unauthorized → authentication failed (credentials).
• 500 – Server Error → failure on external system.

---

What Is Flow HTTP Callout?

Salesforce often needs to communicate with external applications (payment systems, policy systems, verification services, ERP). To do this, Salesforce uses APIs, and the most common type is HTTP. Earlier, integrations were implemented mainly with Apex callouts, which required coding, test classes, and longer development time. Flow HTTP Callouts solve these problems by enabling click‑based integrations.

Flow HTTP Callouts are used when: integration logic is simple, real‑time response is required, and business logic already exists in Flow. Just like Batch Apex is used for large data volumes, Flow HTTP Callouts handle simple, real‑time integrations.

How Flow HTTP Callouts Work Internally

1. Flow reaches the HTTP Callout action.
2. Salesforce builds the HTTP request using Flow variables.
3. Salesforce sends the request to the external API.
4. Salesforce waits for the response.
5. Salesforce parses the response JSON.
6. Response fields become Flow variables.
7. Flow continues to the next element.

This process happens synchronously within the Flow transaction.

When to Use Flow HTTP Callouts

• Real‑time Lead integration: Lead created → send immediately to external system → receive ID → save on Lead.
• External validation: Screen Flow sends data to API (address validation, policy checks) → Flow allows or blocks next steps.
• Event‑based notification: Record updated → notify external system (no complex retry logic).

When NOT to Use Flow HTTP Callouts

Avoid them for high‑volume data processing, thousands of records, complex looping, retry mechanisms, or unpredictable API response times. Prefer Queueable Apex, Batch Apex, or Platform Events in those cases.

---

Prerequisites for Flow HTTP Callouts

1. API details: endpoint URL, HTTP method, request JSON, response JSON.
2. Authentication details (known).
3. Named Credential created (recommended for security and reuse).
4. External system accessible from Salesforce.

Configuring Request Data in Flow

Request body must be JSON. Use Flow variables for dynamic values.

{
  "name": "{!$Record.Name}",
  "email": "{!$Record.Email}"
}

Handling API Responses in Flow

Flow parses response JSON and fields become output variables. Use them in Decisions, Assignments, or Record Updates.

Error Handling in Flow HTTP Callouts

Always handle failures. Check HTTP status code → success: continue; failure: log error or update record. Never assume the API always succeeds.

Authentication Using Named Credentials

Named Credentials are recommended: secure storage, no hardcoding, easy deployment, automatic token refresh. Supported types: Basic Auth, OAuth 2.0, API Key.

Real-World End-to-End Example

Requirement: When a Lead is created, send Lead data to an external CRM and store the returned External ID.

Flow Design: Record‑Triggered Flow (After Save) → HTTP Callout (POST) → Send Lead details → Receive External ID → Update Lead record.

Testing Flow HTTP Callouts

Flow HTTP Callouts cannot call real APIs in tests. Use Flow Test feature with sample request/response, validate decision paths, and validate record updates.

Limitations of Flow HTTP Callouts

• Not suitable for bulk processing.
• Limited debugging capabilities.
• No advanced retry logic.
• Payload size limits apply.

Best Practices for Production Use

• Always use Named Credentials.
• Explicitly handle errors (check status codes).
• Keep payloads small.
• Avoid high‑frequency triggers.
• Log failures for audit (create failure records).