4.3 Salesforce Connect, External Objects & Indirect Lookups

Salesforce Connect, External Objects & Indirect Lookups

Traditional data integrations replicate records from outside databases into custom objects using scheduled batch tools or streaming APIs. However, replicating millions of transactional rows (such as historical invoices, ERP ledger entries, or warehouse inventory logs) incurs severe data storage costs, creates synchronization delays, and introduces compliance headaches. Salesforce Connect provides data federation: an architectural framework that queries external endpoints on-demand and renders data seamlessly within the Salesforce user experience without storing it in the database.

---

Salesforce Connect Architecture & Adapters

Salesforce Connect relies on standard web service protocols to establish real-time connections to external systems. When an end user views a record, navigates a list view, or executes a search, Salesforce Connect dynamically generates an HTTP request to the external endpoint, retrieves the payload, converts it into Salesforce object representations, and displays it in the browser.

Core Protocol Adapters

Administrators configure connections by creating an External Data Source in Setup, selecting one of several protocol adapters:

1. OData 2.0 Adapter: Connects to endpoints exposing the Open Data Protocol version 2.0. Uses XML/Atom or JSON formats for RESTful querying of tabular relational data.
2. OData 4.0 Adapter: Connects to endpoints using the modern OData 4.0 specification, offering superior payload compression, rich filtering syntax, and complex data type support.
3. Cross-Org Adapter: Connects one Salesforce organization to another Salesforce organization using the Lightning Platform REST API. Ideal for enterprise mergers and multi-org hub-and-spoke architectures.
4. Custom Adapter: Developed programmatically in Apex using the DataSource namespace. Used when connecting to proprietary legacy systems, mainframe APIs, or third-party web services that do not support standard OData.

High-Value Architectural Benefits

• Zero Salesforce Data Storage: External records reside exclusively in the host database (e.g., SAP HANA, Oracle ERP, Microsoft SQL Server, Amazon Redshift). They consume zero megabytes of Salesforce data storage allocation.
• Real-Time Data Currency: Data is queried on demand, reducing replication delay; freshness still depends on endpoint availability, caching, and the source system.
• Declarative User Experience: To end users, external records look and behave virtually identically to native Salesforce records.

---

External Objects (__x) & Platform Boundaries

When an External Data Source is synchronized, Salesforce automatically provisions External Objects, identifiable programmatically by the API suffix __x (e.g., Invoice__x, ERP_Order__x).

External objects support custom tabs, list views, detail pages, Lightning Record Pages, page layouts, search results, and related lists. However, because external objects represent federated, non-persisted data, the platform enforces strict architectural boundaries that are heavily tested on the Platform App Builder exam:

• No Roll-Up Summary Fields: Master-Detail relationships cannot be formed with external objects. Consequently, administrators cannot create native declarative Roll-Up Summary fields on standard or custom objects to calculate sums, counts, or averages of external records.
• No Record Ownership or Owner-Based Sharing: External objects do not possess an Owner field. Access cannot be governed through Organization-Wide Defaults (OWD), sharing rules, role hierarchies, or manual sharing. Instead, access is governed globally at the External Data Source level (using Named Principal vs. Per-User authentication) and via Object-Level Permissions on Profiles and Permission Sets.
• Formula Field Boundaries: Formulas and roll-up summaries cannot reference fields on external objects. Use a supported Flow query, source-side calculation, or integration design when an external value must participate in business logic.
• Reporting Limitations: External objects support standard Salesforce reports, but they cannot be included in Joined Reports, and analytical filtering capabilities are constrained by the query capabilities of the underlying external OData endpoint.
• Automation Restrictions: External objects can be queried in Flows, but record-triggered flows cannot fire on external object data changes ; an external system can instead publish a platform event that starts a separate platform event-triggered flow.

---

Relationship Types with External Objects

Connecting external records to core CRM records (such as linking an external invoice to an Account or Contact) requires specialized relationship fields. Salesforce provides three distinct relationship models when integrating external objects:

+-----------------------------------------------------------------------------------+
|                    EXTERNAL OBJECT RELATIONSHIP ARCHITECTURE                      |
+-----------------------+-----------------------+-----------------------------------+
|   RELATIONSHIP TYPE   |      PARENT TYPE      |            CHILD TYPE             |
+-----------------------+-----------------------+-----------------------------------+
| Standard Lookup       | Standard / Custom     | External Object (__x)             |
|                       | (Requires external system to store 18-character SFDC IDs) |
+-----------------------+-----------------------+-----------------------------------+
| External Lookup       | External Object (__x) | Standard, Custom, or External     |
|                       | (Matches on Parent External Object's External ID field)   |
+-----------------------+-----------------------+-----------------------------------+
| Indirect Lookup       | Standard / Custom     | External Object (__x)             |
|                       | (Matches on Parent Custom Field: External ID + Unique)    |
+-----------------------+-----------------------+-----------------------------------+

1. Standard Lookup Relationship

• Architecture: A standard lookup relationship field created on an external child object pointing to a standard or custom parent object .
• Key Constraint: The external database must explicitly store and supply the 18-character Salesforce Record ID in the corresponding foreign key column.
• Real-World Limitation: Legacy systems and enterprise ERPs rarely store internal Salesforce record IDs, making Standard Lookups impractical for most real-world data federation projects.

2. External Lookup Relationship

• Architecture: Used when the PARENT record in the relationship is an External Object (__x).
• Child Objects: The child record can be a Standard Object (e.g., Asset, Case), a Custom Object, or another External Object.
• Matching Mechanism: The child record's lookup field matches against the standard External ID field of the parent external object.
• Enterprise Scenario: A company maintains its authoritative product catalog in SAP, exposed in Salesforce as SAP_Product__x. Administrators create an External Lookup relationship on the standard Asset object pointing to SAP_Product__x. When technicians inspect an installed asset, they link it directly to the external product record.

3. Indirect Lookup Relationship (The Core Integration Workhorse)

• Architecture: Links an external child object (__x) to a standard or custom parent object (such as Account or Contact) without requiring the external system to know or store Salesforce Record IDs.
• Prerequisites on Parent: The parent standard or custom object must contain a custom field configured with BOTH the External ID and Unique attributes (e.g., ERP_Customer_Number__c on Account).
• Matching Mechanism: On the child external object (Invoice__x), the administrator creates an Indirect Lookup field and maps it to the parent's unique External ID field. The external child table supplies its own native customer identifier (e.g., CUST-90210), which Salesforce dynamically matches against Account.ERP_Customer_Number__c.
• Enterprise Scenario: An Oracle billing database stores millions of historical invoices containing an Account_Number column. In Salesforce, Account records have an Account_Number__c field marked as External ID and Unique. An Indirect Lookup on Invoice__x immediately surfaces all matching Oracle invoices as a related list directly on the Account detail page!

---

External Object Relationship Architecture Comparison

Official Source Check

Checked October 19, 2026: External relationship considerations.

Checked October 19, 2026: Formula external-object restrictions.