Salesforce Connect: Federated Data Without Migration

The Case for Federated Data

Every enterprise has systems of record that predate Salesforce — an ERP, a legacy CRM, a data warehouse. The classic integration choice is: replicate the data into Salesforce or query it live. Replication is reliable and fast but creates a second copy that can drift out of sync. Live query is always current but adds latency and creates a dependency on the remote system's availability.

Salesforce Connect is the native mechanism for live query. It surfaces external data inside Salesforce as External Objects — metadata constructs that behave like Salesforce objects (standard fields, relationships, SOQL support) but store nothing. Every record lookup hits the remote source in real time.

Connect Architecture: How It Works

The architectural components of Salesforce Connect are:

• External Data Source: The configuration record that defines the remote system — its URL, auth type (OAuth, Named Credentials, Basic), protocol (OData 2.0, OData 4.0, Apex custom adapter, AWS, Google BigQuery).
• External Object: A Salesforce metadata object (suffix __x) that maps to a table or entity in the external system. Fields map to columns.
• External Lookup Relationship: A special relationship field that links a standard/custom Salesforce object to an External Object. Unlike a standard lookup, it uses the ExternalId field as the join key.
• Indirect Lookup Relationship: Links an External Object to a Salesforce object using any uniquely indexed external ID field — useful when the external system has its own identifier.

-- External Object field naming conventions
Orders__x          (External Object for Orders entity)
OrderId__c         (external ID field on Opportunity — join key)
Order__r           (relationship field name on Opportunity)

-- SOQL to query external data
SELECT Id, Name, OrderDate__c, TotalAmount__c
FROM Orders__x
WHERE AccountExternalId__c = 'ACC-12345'

-- Joining via lookup (from Opportunity)
SELECT Id, Name, Order__r.TotalAmount__c
FROM Opportunity
WHERE AccountId = '001...'

Adapter Types and When to Use Each

Salesforce Connect ships with three built-in adapter types plus a custom Apex adapter framework:

• OData 2.0 / 4.0: The default for REST APIs that support the OData standard. SAP, Microsoft Dynamics, and many other enterprise systems expose OData endpoints. Choose OData 4.0 when available — it supports more data types and has better error handling.
• Cross-Org Adapter: Connects one Salesforce org to another. Useful for shared data across org splits — a parent company org and subsidiary orgs can share Account data without replication. Authentication uses the same org's OAuth flow.
• Amazon DynamoDB / Google BigQuery: Direct connectors for cloud data stores. Useful for analytics-adjacent use cases where large datasets need to be surfaced contextually.
• Custom Apex Adapter: Implement DataSource.Connection and DataSource.Provider interfaces. Full control over the HTTP call, field mapping, and query translation. Required when the remote system does not expose OData.

// Custom Apex Adapter skeleton
global class MyERPAdapter extends DataSource.Connection {
  override global List<DataSource.Table> sync() {
    List<DataSource.Column> cols = new List<DataSource.Column>{
      DataSource.Column.text('ExternalId', 255),
      DataSource.Column.text('Name', 255),
      DataSource.Column.number('TotalAmount', 18, 2)
    };
    return new List<DataSource.Table>{
      DataSource.Table.get('Orders', 'ExternalId', cols)
    };
  }

  override global DataSource.TableResult query(DataSource.QueryContext ctx) {
    // Build HTTP request to external ERP
    // Transform response to DataSource.Row list
    List<Map<String,Object>> rows = callExternalERP(ctx);
    return DataSource.TableResult.get(ctx, rows);
  }
}

Governor Limits and Performance Reality

Connect calls count against Salesforce callout limits, not query limits. Each External Object query generates one or more callouts to the external system:

• Max 100 callouts per Apex transaction
• Callout timeout limit: 120 seconds
• No async callout support — Connect queries are synchronous
• External Object row limit per query: 2,000 rows

The 2,000 row limit is a hard ceiling. If the external system has 50,000 orders, a Connect query can only ever show the first 2,000 (ordered by the default sort). This makes Connect unsuitable for bulk data analysis — it is designed for contextual, record-level lookups, not reporting.

When Connect Is the Right Choice

Connect excels in three scenarios:

1. Contextual data access: A sales rep opens an Account and needs to see the last three ERP orders without IT building a full sync pipeline. One External Object with an Account relationship delivers this in a single afternoon.
2. Cross-org data visibility: A service team org needs read access to Account data owned by the sales org. The Cross-Org adapter provides this without a full merge or complex middleware.
3. Compliance-constrained data: Data that legally cannot be replicated (GDPR-sensitive PII, regulated financial records) can be surfaced via Connect without being stored in Salesforce storage.

Security and Caching Considerations

External Objects honour Salesforce object-level and field-level security. FLS and object permissions apply as expected. However, row-level security (record ownership, sharing rules, territory management) does not apply to External Objects — all users with object access can see all returned rows unless the external system enforces row-level filtering.

For caching, OData adapters have no built-in cache. Each page load triggers a fresh callout. If the external system's API has strict rate limits, Connect can inadvertently exhaust them during peak Salesforce usage. Co-ordinate with the external system's team before production deployment.