Salesforce Connect | External Data | SalesforceTutorial

Salesforce Connect lets an org read data that stays in another system and present it as external objects in Salesforce. Use it when users need current records from an ERP, order platform, billing database, legacy application, or another Salesforce org without loading that data into standard or custom objects.

This guide explains how Salesforce Connect works, how it differs from salesforce external services, how to set up external data sources, and how developers should query external objects without creating slow pages or unsafe Apex.

What is Salesforce Connect?

Salesforce Connect is a data virtualization feature. It uses an external data source to define how Salesforce reaches an outside system, then maps remote tables or resources to external objects. External objects look similar to custom objects in Setup and in the UI, but their API names end with __x instead of __c.

The important design point is ownership. A custom object stores its records in Salesforce. An external object usually leaves the record in the source system and retrieves it when a user opens a record page, list view, lookup, related list, search result, SOQL query, or supported automation path. That is why Salesforce Connect fits reference and operational lookup use cases better than bulk analytics use cases.

Official setup paths and adapter behavior are covered in Salesforce Help for setting up Salesforce Connect and the Salesforce Help documentation for OData adapters.

Salesforce Connect use cases and limits

In enterprise orgs, Salesforce Connect is most useful when the external system remains the system of record. For example, service agents can view warranty claims from a claims platform, sales users can inspect invoice status from ERP, and partner users can see shipment records without copying millions of rows into Salesforce.

Salesforce Help notes that OData 2.0, OData 4.0, and OData 4.01 adapters for Salesforce Connect do not use the normal Apex callout limit for Salesforce-to-external reads, but the external system can still throttle or fail. Build pages as if the remote system can be slow.

How Salesforce Connect works with external objects

The runtime path has four parts: the user requests a page or query, Salesforce checks object and field permissions, Salesforce sends a request through the adapter, and the adapter returns rows that Salesforce displays as external object records. The external system controls the real data; Salesforce controls metadata, security assignment, relationship configuration, and the user experience.

External data sources

An external data source stores the connection configuration. For OData, the endpoint must expose a service root that Salesforce can read. If one system exposes separate services, create a separate external data source for each service endpoint. Use Named Credentials where supported so authentication is not stored directly in code or repeated across components.

External objects and fields

After the external data source is saved, use Validate and Sync to read the remote metadata and create external object definitions. External objects can have custom fields, lookup-style relationships, page layouts, tabs, list views, and permission assignments. The source table or entity key becomes important because Salesforce uses it to identify the external record.

Relationships for external objects

Salesforce supports lookup, external lookup, and indirect lookup relationship patterns with external objects. Use a normal lookup when the child external object points to a Salesforce parent record by Salesforce record ID. Use an external lookup when the parent is another external object. Use an indirect lookup when an external object matches a field on a Salesforce object, such as an external customer number on Account. Salesforce documents these relationship considerations in object relationship considerations and indirect lookup relationship fields.

How to set up Salesforce Connect

The exact fields differ by adapter, but the implementation path is consistent. Test the endpoint outside Salesforce first, then configure the external data source, sync the schema, secure the object, and validate with real users.

1. Confirm licensing and adapter choice. Check your org edition and Salesforce Connect entitlement before design sign-off.
2. Prepare the external API. For OData, confirm the service root, entity sets, keys, supported filters, supported sort fields, and authentication model.
3. Create the external data source. In Setup, search for External Data Sources, create a new source, and choose the adapter such as OData 4.0, OData 4.01, cross-org, or custom adapter.
4. Set authentication. Prefer Named Credentials or the adapter-supported authentication model. Avoid embedding secrets in Apex.
5. Validate and Sync. Select only the tables or entities users need. Do not sync every remote entity just because it is available.
6. Assign security. Grant object permissions, field permissions, tab visibility, and page layout access through permission sets or permission set groups.
7. Add relationships and UI. Add external related lists to Account, Contact, Case, or custom object pages only where users need them.
8. Load-test the user path. Test list views, record pages, global search, report-like navigation, and mobile pages with production-sized data and realistic latency.

Salesforce external services vs Salesforce Connect

Salesforce external services is not another name for Salesforce Connect. External Services reads an OpenAPI specification and creates invocable actions that Flow, automation, and supported agent actions can call. Salesforce Connect creates external objects for record-style access. The official Salesforce Help page for External Services explains that it creates invocable actions from API descriptions.

Choose salesforce external services when the external API performs an action, such as calculating tax, checking eligibility, creating a bank account, or submitting a document. Choose Salesforce Connect when users need to browse, search, or relate external records as part of a Salesforce record model.

Is s f connect the same feature?

Some users search for s f connect when they mean Salesforce Connect. In Salesforce Setup and documentation, use the official name because it maps to the feature, the adapter documentation, and the licensing language. The phrase s f connect can also be confused with generic Salesforce integrations, connected apps, or mobile sync.

What can you connect with Salesforce?

The search question what can you connect with salesforce has more than one answer. With Salesforce Connect specifically, you can connect OData services, another Salesforce org through the cross-org adapter, or custom endpoints through the Apex Connector Framework. With other Salesforce integration tools, you can also connect REST APIs, SOAP APIs, Bulk API jobs, Platform Events, Change Data Capture, MuleSoft APIs, Flow HTTP Callouts, External Services actions, and Data Cloud ingestion paths. The right answer depends on whether users need virtual records, automation actions, event-driven integration, or copied data.

SOQL and Apex examples for external objects

External objects can be queried in SOQL when the adapter and external source support the query shape. Use selective filters, keep result sets small, and include LIMIT. A page that queries an external object without filters can turn one user click into an expensive remote request.

SELECT ExternalId, Status__c, Total__c, Account_Key__c
FROM Order_Summary__x
WHERE Account_Key__c = 'ACME-1007'
AND Status__c = 'Open'
ORDER BY ExternalId ASC
LIMIT 50

The next Apex example is written for API v60.0+ syntax and uses a made-up external object named Order_Summary__x. Replace the object and field names with the external objects generated in your org. The code checks object and field access before querying, keeps the query selective, and returns only the columns the UI needs.

public with sharing class ExternalOrderLookup {
    @AuraEnabled(cacheable=true)
    public static List<Order_Summary__x> openOrdersForAccount(String accountExternalKey) {
        if (String.isBlank(accountExternalKey)) {
            return new List<Order_Summary__x>();
        }

        if (!Schema.sObjectType.Order_Summary__x.isAccessible()) {
            throw new AuraHandledException('You do not have access to order summaries.');
        }

        if (!Schema.sObjectType.Order_Summary__x.fields.ExternalId.isAccessible()
            || !Schema.sObjectType.Order_Summary__x.fields.Status__c.isAccessible()
            || !Schema.sObjectType.Order_Summary__x.fields.Total__c.isAccessible()
            || !Schema.sObjectType.Order_Summary__x.fields.Account_Key__c.isAccessible()) {
            throw new AuraHandledException('You do not have access to the required order fields.');
        }

        return [
            SELECT ExternalId, Status__c, Total__c, Account_Key__c
            FROM Order_Summary__x
            WHERE Account_Key__c = :accountExternalKey
            AND Status__c = 'Open'
            ORDER BY ExternalId ASC
            LIMIT 50
        ];
    }
}

Do not assume an external object behaves like a local table. The adapter can reject unsupported filters, the external endpoint can return errors, and list views can feel slow if users add broad filters. In LWC, cache only read methods that are safe to cache, show a clear empty state, and avoid automatic refresh loops against external data.

Apex Connector Framework for custom adapters

Use a custom adapter only when the external system cannot expose supported OData or cross-org data and you still need external object behavior. The Apex Connector Framework uses classes in the DataSource namespace. A provider class tells Salesforce what the adapter supports and creates the connection. A connection class handles sync, query, and search behavior. Salesforce documents this pattern in the Salesforce Connect Apex Developer Guide and the DataSource namespace reference.

In production, treat a custom adapter as integration code. Implement timeouts, error mapping, pagination, filter translation, test coverage, and logging. Keep the adapter bulk-aware because list views, related lists, and search can call it in patterns that differ from a single record page. If the source API cannot filter by the fields users search, do not hide that limitation in Apex. Redesign the source API or choose a synchronization pattern.

Security and permission design for Salesforce Connect

Salesforce security still matters even when the data lives outside Salesforce. Assign external object access with permission sets, restrict fields with field-level security, and control the pages and related lists where users can view external records. If the external source uses per-user authentication, confirm that each user can access only the external records they should see. If the external source uses a shared integration identity, enforce row-level restrictions in the external service or in the adapter design.

For Experience Cloud, partner, or customer access, validate the full path: login user, permission set, external object CRUD, field access, external system identity, and source-side authorization. A misconfigured shared credential can expose more data than intended even if Salesforce page layouts look correct.

Best practices for Salesforce Connect implementations

• Start with a user task. Do not connect every external table. Connect the records users must read or edit in Salesforce.
• Design for small result sets. External related lists and list views should use filters that the source system can process.
• Use stable keys. External IDs and indirect lookup keys should not change when the source system renames or merges records.
• Plan for downtime. Add support messages and operational alerts for source system outages.
• Separate read and action patterns. Use Salesforce Connect for external records and salesforce external services or Apex callouts for external actions.
• Document adapter limits. Write down supported filters, sort fields, writable behavior, search behavior, and known source throttles.
• Test with production latency. A related list that works in a sandbox with sample data can fail user acceptance testing when the ERP adds real response time.

Common errors with Salesforce Connect

Salesforce Connect decision checklist

Use Salesforce Connect when the answer to these questions is yes:

• Does the external system remain the source of truth?
• Do users need current records in Salesforce, not a nightly copy?
• Can the source system filter and return small result sets quickly?
• Can you secure the data with the right user or integration identity?
• Can the business accept partial impact when the external system is unavailable?

Choose another integration pattern when users need large-scale analytics, offline access, complex transformations, or guaranteed local reporting. For adjacent topics, see Salesforce Data Loader import patterns, Salesforce Flow automation design, Lightning Web Components data access, and Salesforce reports and dashboards.

Frequently Asked Questions