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.
Quick Answer
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.
Key Takeaways (TL;DR)
- What it is: Salesforce Connect surfaces external data as external objects without copying it into your org.
- Licensing: Connect is an add-on license priced per connection — confirm current pricing with your Salesforce account team.
- Authentication: named credentials plus external credentials handle endpoints and secrets securely.
- Best for: live, read-heavy visibility into external systems from inside Salesforce.
- How Vantage Point helps: integration architecture and build through our system integration and data migration services.
What Is Salesforce Connect?
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.
How Do Salesforce Connect Adapters Work?
| 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.
Is Salesforce Connect Included, or an Extra License?
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:
- You may not need many connections. One connection can expose multiple external objects from the same source, so a single well-designed endpoint can cover an entire external system.
- Verify feature availability in your sandbox. Teams occasionally discover mid-build that their environment lacks the external-data features they planned on. Confirm Connect is provisioned and enabled before committing to the design.
What Are the Limitations of External Objects?
External objects behave like Salesforce records, but not completely. Before choosing Connect, validate that your use case survives its constraints:
- Not every platform feature applies: triggers, some automation, and certain reporting behaviors are limited or unavailable on external objects. Check the current Salesforce documentation against your specific requirements.
- Performance depends on the source: every list view and record page queries the external system live. A slow or rate-limited source becomes a slow Salesforce page.
- Search and indexing are constrained: external objects are not searched the same way as native records by default.
- Write support varies by adapter: read-only is the common case; writes depend on the adapter and the source system's API.
Salesforce Connect vs. Custom Integration vs. Replication
| 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?
What Are Common Salesforce Connect Use Cases?
- Order and invoice history from an ERP: sales and service teams see live order status on the account record without duplicating years of transactional history into Salesforce storage.
- Data-platform reference data: usage metrics, product telemetry, or analytics outputs stay in the warehouse but appear as related lists where teams already work.
- Org-to-org visibility: the cross-org adapter lets related business units or post-acquisition orgs share records without middleware or a merge project.
- Legacy system retirement: keep read access to a system being decommissioned through Connect while new work moves to Salesforce, instead of migrating every historical record.
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.
When Is a Custom Apex Adapter the Right Call?
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.
What Should Businesses Do Next?
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.
How Vantage Point Helps
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.
Need External Data Inside Salesforce?
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.
Frequently Asked Questions
What is Salesforce Connect used for?
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.
Does Salesforce Connect come with our licenses?
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.
What is the difference between a named credential and an external credential?
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.
Can Salesforce Connect write back to the external system?
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.
What if our data source has no OData endpoint?
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.
When should we replicate data instead of using Salesforce Connect?
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.
