External Data Source
An External Data Source is a Salesforce configuration record that defines how your org connects to data stored outside Salesforce.
Definition
An External Data Source is a Salesforce configuration record that defines how your org connects to data stored outside Salesforce. It captures the endpoint, the adapter type, the identity (authentication) details, and any options the connection needs. Systems on the far end can be an OData service, another Salesforce org, an Amazon DynamoDB table, a SQL database, or a custom system reached through Apex. You create and manage these records in Setup under External Data Sources.
The record itself moves no data. It is the connection definition that Salesforce Connect reads when it queries the external system live, or that Files Connect reads when it surfaces external files. After you create an External Data Source, you validate and sync it. The sync maps the external system's tables to external objects in your org, each named with the __x suffix, so users can search and report on data that never leaves the source.
How an External Data Source connects Salesforce to outside data
The connection record, not a copy of the data
An External Data Source is a definition, not storage. When you save one, Salesforce records where the external system lives, which adapter speaks to it, and how to authenticate. No external rows land in your org at this point. The data stays in the source system, and Salesforce holds only a pointer plus the metadata it needs to call out. This separation is the whole idea. Your ERP keeps invoices, your CRM keeps accounts and opportunities, and the External Data Source links them so an agent sees both in one screen. Because nothing is copied, you skip the ETL pipeline, the nightly sync job, and the storage cost of duplicating records you do not own. The tradeoff is a live dependency. If the source is slow or down, the linked data is slow or unavailable too. You manage these records in Setup under External Data Sources, where you also validate and sync them.
Validate, sync, and the external objects you get
Creating the record is step one. Step two is validate and sync. Validation confirms Salesforce can reach the endpoint and authenticate. Sync reads the external system's schema and creates or updates external objects in your org, one per table you select. Each external object carries the __x suffix, the way custom objects carry __c, which is how you tell them apart at a glance. These external objects behave a lot like custom objects. They get tabs, list views, page layouts, and they show up in search and reports. The difference sits underneath. When a user opens a report on an external object, Salesforce does not read local rows. It issues a web service callout to the source and returns what comes back. SOQL against an external object is translated into a request to the adapter at query time. Re-running sync after a schema change keeps the external objects aligned with the source, so a new column in the source can become a new field in Salesforce.
Adapters: OData, cross-org, and custom Apex
The adapter type on the record decides what protocol Salesforce speaks. The OData adapters cover OData 2.0, 4.0, and 4.01, which is the common path for modern systems that already expose an OData producer. The cross-org adapter connects one Salesforce org to another, so a parent org can read child-org data as external objects. The custom adapter uses the Apex Connector Framework, which lets a developer connect to almost any REST-reachable system that does not speak OData. Salesforce has added more adapters over time. There are now options for Amazon DynamoDB, SQL databases, GraphQL services, and Amazon RDS, each packaged so admins configure rather than code. Pick the adapter that matches what the source actually exposes. If the source publishes OData, use the OData adapter. If it is a bespoke API with no standard contract, the Apex Connector Framework is the escape hatch, at the cost of writing and maintaining Apex.
Identity type and authentication
The Identity Type field controls whose credentials Salesforce uses to reach the source. Anonymous means no credentials, which suits public, read-only services. Named Principal means one shared set of credentials for every user in the org, so everyone sees the same external account. Per User means each Salesforce user supplies and manages their own credentials, so the source can apply its own per-person access rules. On top of identity type sits the authentication protocol. Options include no authentication, password (basic) authentication, and OAuth 2.0, and OAuth works with both Named Principal and Per User setups. In current orgs the cleaner pattern is to back the External Data Source with a Named Credential, which holds the endpoint and secret separately and handles the OAuth token lifecycle for you. Per User is powerful when each person must act as themselves in the source, but it adds setup and support work because every user has to authenticate before their external data appears.
Live callouts, caching, and writable rows
By default every query against an external object is a live callout, so the data is as fresh as the source. That freshness has a price in latency and in load on the external system. To soften both, an adapter can cache results so repeated reads of slow-changing data do not hammer the source. A product catalog or a country list is a good caching candidate. A live balance or an open order usually is not, because a stale number there is worse than a slow one. External objects can also be writable, not just readable. With a writable setup, a user editing an external object record sends the change back to the source through the adapter. That turns Salesforce into a front end for the system of record, not only a viewer of it. Writable behavior depends on the adapter and on the source accepting writes, so confirm both before you design an edit experience on top of external data.
Limits, licensing, and the live dependency
Salesforce Connect is a licensed capability, and the number of external objects an org can have is capped, so you plan which tables to expose rather than syncing everything. The OData adapters historically applied hourly callout limits. Starting with Spring 25, those limits were removed for OData 4.01 on orgs running Hyperforce, rolling out over time. When a source returns rate-limit errors, the High Data Volume option on the External Data Source bypasses most of those limits, though it changes some behavior in return. The constraint that bites most teams is not a number, it is the dependency itself. An external object is only as available as the system behind it. If the ERP has a maintenance window, reports and pages built on its external objects fail during that window. Test against production-scale volumes too. A query that returns fifty rows in a sandbox can time out at several thousand rows in production, where the source, the network, and the row count all work against you.
How to set up an External Data Source
You define an External Data Source in Setup, then validate and sync it to generate external objects. These steps assume an OData source, which is the most common starting point.
- Open External Data Sources in Setup
From Setup, enter External Data Sources in Quick Find and select it. Click New External Data Source to start a fresh record.
- Pick the adapter type
Set Type to the adapter that matches the source, such as Salesforce Connect: OData 4.01 for a modern OData producer or a cross-org or custom Apex option for other systems.
- Enter the endpoint and identity
Provide the URL of the source. Set Identity Type to Anonymous, Named Principal, or Per User, and choose the authentication protocol, ideally pointing at a Named Credential for OAuth.
- Validate and sync
Save, then click Validate and Sync. Select the tables you want, and confirm to create the matching external objects with the __x suffix in your org.
The protocol Salesforce uses: OData 2.0 / 4.0 / 4.01, cross-org, custom Apex, or a packaged adapter like DynamoDB or SQL.
Whose credentials are used: Anonymous (none), Named Principal (one shared set), or Per User (each user manages their own).
Bypasses most callout rate limits for high-traffic sources, with some behavior tradeoffs you should review first.
- Re-run sync after the source schema changes, or your external objects drift out of date.
- Per User identity means every user must authenticate before their external data shows up; plan the support overhead.
- External objects are only as available as the source; a source outage breaks reports and pages built on them.
Prefer this walkthrough as its own page? How to External Data Source in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on External Data Source.
Hands-on resources to go deeper on External Data Source.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does an External Data Source record define in Salesforce?
Q2. Which authentication pattern is valid for an External Data Source that connects to a public OData service?
Q3. What does an External Data Source let a Salesforce user do without copying records into Salesforce?
Discussion
Loading discussion…