Mastering Salesforce Connect: External Objects, External Services & Data Virtualization

💬 In plain words: Salesforce Connect allows you to view external data inside Salesforce as "External Objects." You can see and query the rows as if they were local records, but they actually live in another system—meaning zero data replication and no storage costs. On the other hand, External Services takes an API's OpenAPI specification and automatically turns it into ready-to-use Flow actions without requiring a single line of Apex code.

📌 Real-Life Example: Imagine your sales team needs to see SAP purchase orders directly on the Salesforce Account page. There are millions of rows, they are mostly read-only, and the data must remain mastered in SAP. By setting up a Salesforce Connect external object, those SAP rows appear like standard Salesforce records and are live-fetched via OData. You save massive storage costs because you aren't copying millions of rows into Salesforce.

🧠 Core Takeaway: A window, not a copy. External objects provide a live window into another system. You see the rows, you interact with them, but you do not store them in your org.

⚡ Key Points: 1-Minute Summary

• Salesforce Connect (Data Virtualization): Surfaces data from external systems inside Salesforce without copying it. Ideal for massive datasets that only need to be viewed occasionally.
• ETL (Data Import): Physically copies data into standard Salesforce objects. Required when you need robust reporting, Apex triggers, offline access, or complex automation.
• External Services: A declarative tool that consumes an OpenAPI (Swagger) JSON/YAML spec and generates Invocable Actions for Salesforce Flow, completely bypassing the need for custom Apex callouts.
• External Objects (__x): Suffer from distinct platform limitations, including no Apex triggers, limited SOQL capabilities, and strict callout rate limits.

🏗️ The Core Concept: Virtualization vs. Action

The foundation of this architecture is Data Virtualization. Salesforce Connect maps external data tables to External Objects (identified by the __x suffix). Salesforce connects to these external databases using standard protocols like OData 2.0, OData 4.0, a Cross-Org adapter, or a custom Apex adapter.

• The data remains securely in the source system and is queried live at runtime.
• You can use External Lookups or Indirect Lookups to relate these external rows to native Salesforce records (like Accounts or Contacts).
• The Trade-off: You eliminate storage costs and synchronization headaches, but you inherit a set of functional limits: no Apex triggers, restricted SOQL functionality, API callout latency on every page load, and specific licensing costs.

External Services is a fundamentally different capability. While Salesforce Connect handles records, External Services handles actions. It imports an OpenAPI specification and dynamically generates invocable actions. This gives Admins the power to make complex REST API callouts directly from a Salesforce Flow without writing custom Apex client code.

🧭 360 Card — Salesforce Connect & External Objects

Rule: Virtualize data when Salesforce only needs to view it. Copy the data (ETL) when Salesforce must own it, automate heavily on it, or report on it comprehensively.
Gain: No sync jobs, no data staleness, and zero Salesforce storage costs. The source of truth remains untouched.
Reach for: A hybrid approach is usually best. Copy the two or three specific fields you need for automation or reporting into standard objects, and use Salesforce Connect to virtualize the remaining 40 fields for UI viewing.
Price: Every single list view or record page load makes a live API callout. The user experience is entirely dependent on the external system being online and fast.
Limits: External objects cannot trigger automation. They have highly restricted reporting and no aggregation capabilities. While writable external objects exist, writes are sent directly to the source system, inheriting its validation rules and latency.
Mirror (ETL Data Import): Importing data gives you full reporting, automation, and sharing capabilities—but forces you to manage sync schedules, data staleness, and expensive storage bills.
At volume: Millions of rows glanced at occasionally is the ideal use case. Millions of rows queried and updated constantly is an architecture failure waiting to happen.

⚠ INTERVIEW TRAP: If an interviewer asks how to display millions of historical, read-only ERP records in Salesforce, do NOT say "ETL and copy it in." Replicating massive datasets that Salesforce doesn't own is a red flag. That is the exact scenario Salesforce Connect was built for.

💬 Core Q&A

Q: When is Salesforce Connect the right choice versus ETL-ing the data in?

🎯 Say this first: "Connect when the data must remain external and you only need to read it on demand. Copy it in when you need native reporting, sharing, and automation."

A: Salesforce Connect wins in three specific scenarios:

• The dataset is massive but touched rarely (e.g., millions of archived ERP invoice lines viewed occasionally on an Account page).
• The source system must remain the absolute system of record, requiring zero-second staleness.
• Strict compliance regulations forbid copying the data into the cloud.

ETL (Extract, Transform, Load) and sync wins when:

• The data feeds complex reports and dashboards (External Objects cannot handle robust aggregations).
• The data drives automated processes, as External Objects do not support Apex triggers.
• Offline resilience is required (Connect fails if the remote endpoint goes down).
• The data is queried "hot and often", where OData callout limits and network latency would ruin the user experience.

(Note: For massive analytical datasets, Salesforce Data Cloud's "Zero Copy" architecture is becoming the modern alternative to standard transactional OData connections.)

🔍 Scenario-Based Follow-Ups

Q: What are the practical limits of external objects that surprise teams post-go-live?

A: You must set expectations during the design phase, because users will immediately hit these walls:

• Reporting is highly constrained. You get basic tabular reports, but none of the standard dashboard aggregation freedom.
• SOQL limitations. Aggregation functions (like COUNT()) and certain filters are either unavailable or pushed to the remote server, which may just reject them depending on the adapter.
• Global Search only works if the OData adapter specifically supports it.
• Page performance is hijacked by the remote system's latency. If the external ERP is slow today, Salesforce is slow today.
• Rate Limits. There are strict hourly OData callout limits.

Q: A Flow needs to call a REST API to validate a shipping address. Do you write Apex?

A: Not initially. Your first move should be to register the provider's OpenAPI specification in External Services.

• The platform automatically generates typed Invocable Actions.
• The Flow calls these actions directly, authenticated securely via Named Credentials (or the modern External Credentials architecture).
• No Apex code is written, meaning no test classes and easy maintenance for Admins.

You should only escalate to custom Apex if:

• The API provider doesn't have a valid OpenAPI spec.
• The JSON response requires complex parsing, transformation, or enrichment that Flow cannot handle efficiently.
• You require heavy enterprise error handling, like retry loops and circuit breakers.

Q: Can users edit records on an External Object?

A: Yes, writable external objects exist for OData adapters. However, the architecture is essentially a synchronous API call wearing a record page's clothing. The write operation goes straight through to the external system. It is bound by that system's validation rules, network latency, and availability. Keep external writes rare, ensure you have crystal clear error handling on the UI, and architect it knowing it behaves nothing like a standard Salesforce local commit.