Your customer data lives in Salesforce, but some of the data your teams need lives somewhere else — a cloud data warehouse, a data platform, another Salesforce org, or a line-of-business system. The question every architecture conversation eventually hits: do we copy that data into Salesforce, or do we show it there without moving it?
Salesforce Connect exists for the second option. It surfaces external data as "external objects" that look and behave like Salesforce records, without storing the data in your org. But it is a paid add-on with real limitations, and it is not the only way — sometimes a custom API integration or a managed data sync is the better answer.
This guide explains what Salesforce Connect is, how the licensing works, and how to decide between Connect, a custom integration, and a full data replication approach.
Salesforce Connect is a paid Salesforce add-on that lets your org display and interact with data stored in external systems — via external objects — without importing it. It connects through adapters (cross-org, OData, or a custom Apex adapter) authenticated with named credentials and external credentials. It is a good fit when users need live, read-mostly access to external data inside record pages, related lists, and reports. It is a poor fit when you need heavy processing, complex joins, or full platform features on that data — in those cases, a custom API integration or a replication strategy usually wins. Vantage Point designs and builds both patterns for clients.
Salesforce Connect is the platform's data virtualization feature. Instead of loading external data into Salesforce objects, you define an external data source and Salesforce generates external objects — records that are fetched from the external system on demand and rendered in the familiar Salesforce UI.
Users can view external object records on related lists, include them in lookups, and reference them in page layouts, all without the data ever being stored in Salesforce. The most common sources are other Salesforce orgs (via the cross-org adapter), OData services, and custom endpoints reached through an Apex adapter.
| Adapter | What it connects to | When to use it |
|---|---|---|
| Cross-org adapter | Another Salesforce org | Sharing records between orgs without middleware or replication |
| OData 2.0 / 4.0 adapter | Any system exposing an OData endpoint | Standard, no-code connection when the source system (or middleware) can publish OData |
| Custom Apex adapter | Anything with an API — including cloud data platforms | When the source has no OData option; a small Apex class translates Salesforce queries into API calls |
Authentication is handled by named credentials (the endpoint definition) and external credentials (the principals and secrets, such as API keys, OAuth, or AWS-style signatures). This keeps credentials out of code and gives admins a supported, auditable way to manage them. In practice, the hardest part of a Connect project is often not the adapter — it is matching the source system's authentication model to what named credentials support.
Salesforce Connect is an add-on license, not included in standard editions, and it is priced per connection (per external data source). Community listings have long quoted it in the thousands of dollars per connection per month, but pricing changes and is often negotiated — confirm current numbers with your Salesforce account team before scoping a project around it.
Two practical licensing notes:
External objects behave like Salesforce records, but not completely. Before choosing Connect, validate that your use case survives its constraints:
| Approach | How it works | Strengths | Watch out for |
|---|---|---|---|
| Salesforce Connect | Live query of external data as external objects | No data duplication; always current; native UI | Add-on cost; feature limits; dependent on source uptime and speed |
| Custom API integration | Apex callouts or middleware pull/push specific data | Precise control; can transform and enrich; no Connect license needed | You own the code, error handling, and API limits |
| Replication / sync | Data copied into Salesforce on a schedule or in near-real time (ETL, MuleSoft, Data Cloud) | Full platform features; fast reporting; works offline from source | Storage costs; staleness; sync failures to monitor |
The deciding questions are usually: How fresh does the data need to be? Do users need to act on it with full Salesforce features? How much data is it? And what does the source system's API actually support?
The pattern across all four: the data is valuable in context, accessed frequently but processed rarely, and expensive or risky to copy. When that description stops fitting, replication or a custom integration usually takes over.
If the source system has no OData endpoint — common with cloud data warehouses and proprietary platforms — a small custom Apex adapter lets Salesforce Connect talk to it anyway. The adapter translates Salesforce's queries into the source's API calls and maps responses back into external object rows.
This is a well-trodden pattern, but it is real code with real ownership: someone must maintain it when the source API changes. If your team also needs transformation, validation, or write-back logic, a middleware-based integration often absorbs that complexity better than stretching an adapter.
Start with the use case, not the tool. List the exact data elements users need inside Salesforce, how current they must be, and what users will do with them. Then confirm three technical facts: whether your org has (or can license) Salesforce Connect, what authentication model the source system supports, and whether the source can publish OData or will need a custom adapter. Those three answers usually make the architecture decision for you.
Vantage Point designs and builds the full spectrum of Salesforce integration patterns — Salesforce Connect configurations, custom Apex adapters, and middleware architectures on MuleSoft. Our system integration and data migration team handles the authentication, endpoint, and licensing questions that stall these projects. We've completed 400+ engagements for 150+ clients, with a 4.71/5.0 average engagement rating and 95% client retention. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Vantage Point can assess your source systems, licensing position, and use cases, then recommend — and build — the right integration pattern. Talk to Vantage Point about your integration architecture.
Salesforce Connect surfaces data stored in external systems as external objects inside Salesforce, so users can view and relate that data in record pages, related lists, and layouts without importing or storing it in the org.
Usually not. Salesforce Connect is a paid add-on, licensed per connection to an external data source. Pricing changes over time, so confirm the current cost and whether your edition qualifies with your Salesforce account team.
A named credential defines the endpoint — the URL of the external system. An external credential defines how to authenticate to it, including principals and secrets such as API keys or OAuth configurations. Together they keep credentials out of code and manageable by admins.
It depends on the adapter and the source system's API. Read-only access is the common pattern; write support varies. Validate write requirements explicitly during design rather than assuming them.
You can build a small custom Apex adapter that translates between Salesforce Connect and the source system's API, or put middleware in front of the source to publish an OData endpoint. Both are proven patterns; the right choice depends on who will maintain it.
Replicate when users need full Salesforce platform features on the data — complex reporting, automation, or heavy processing — or when the external system is too slow or rate-limited to serve live queries. Replication trades freshness for capability.