What Salesforce Connect Actually Does

Salesforce Connect lets you view and interact with data stored in external systems as if it were Salesforce data — without copying. External Objects behave like custom objects in the UI, in SOQL, in flows, and in related lists — but the underlying data lives in a database, a REST API, or an OData service elsewhere.

Think of it as data virtualization for Salesforce. No ETL. No sync jobs. No duplicate storage costs.

The Core Tradeoff

Virtualization vs. replication is the fundamental choice.

Replication (copy data into Salesforce):

  • Fast queries (data is local).
  • Works offline if Salesforce is available.
  • Storage cost in Salesforce.
  • Sync logic to build and maintain.
  • Data is as fresh as the last sync.

Salesforce Connect (virtualize):

  • Always fresh — reading the source system live.
  • No storage cost.
  • No sync to maintain.
  • Queries are slower (network round trip).
  • Source system availability affects Salesforce user experience.

Neither is “better.” The right choice depends on freshness needs, volume, query patterns, and performance tolerance.

When to Use Salesforce Connect

Always-fresh requirements. Compliance data, current inventory, live account balances — staleness would be harmful.

Large data volumes in the source. Replicating millions of records would blow Salesforce storage limits.

Sensitive data better left in the source of record. Regulated data you can’t move.

Read-heavy, low-write patterns. Virtual is more efficient for reading; writes are possible but add complexity.

Occasional views. Data you rarely look at doesn’t justify the sync cost.

When to Use Replication Instead

Frequent complex queries. Reports that span external and Salesforce data perform poorly over virtualization.

Offline or partial-availability environments. If users will query when the source is down, replication is safer.

High-volume writes. External Objects support writes but the constraints are nontrivial.

Small, stable data. A few thousand records that rarely change are cheap to replicate.

Adapter Types

Salesforce Connect supports multiple adapter types. Pick based on your source.

OData 2.0 / OData 4

The easiest. Many databases and middleware expose OData. You configure the External Data Source, Salesforce introspects the service, you create External Objects. Reads and writes both work.

Cross-Org Adapter

Connect to another Salesforce org. One org’s objects appear as External Objects in the other. Use for multi-org deployments.

Custom Apex Adapter

For sources without a standard protocol. You write Apex classes that translate Salesforce’s queries into calls against your source.

This is the escape hatch. If your source is a REST API or legacy system, the custom adapter covers it, but you write and maintain the translation logic.

Setup Walkthrough (OData)

  1. Create an External Data Source.
    • Type: OData 2.0 (or 4)
    • URL: the OData endpoint
    • Identity Type: Named Principal or Per User
    • Authentication: Named Credential referencing your auth setup
  2. Validate and Sync.
    • Salesforce fetches the service metadata.
    • Lists available “tables” (entities).
  3. Create External Objects from tables.
    • Pick which tables to expose.
    • Salesforce creates External Object definitions.
  4. Configure indirect lookup / external lookup relationships.
    • Connect External Objects to native objects via relationships.
  5. Add to page layouts and list views.
    • Expose via the UI.

The process is 80% configuration, 20% validation. Most of the pain is auth.

Performance Considerations

Every query against an External Object is a call to the source. Slow source → slow Salesforce UI.

Tactics to mitigate:

  • Server-side filtering. Salesforce pushes down WHERE clauses when the adapter supports it. Make sure your source handles the filter efficiently.
  • Pagination. External Objects use server-side paging. Don’t list-view 100,000 external rows at once.
  • Selective lookups. When using External Objects in related lists, constrain the query.
  • Caching (where available). Some adapters support short-term caching. Evaluate if freshness allows.

Benchmarks: a well-indexed OData source can serve a typical list view in a second or two. A poorly-indexed source with no server-side filtering can take tens of seconds.

Writes to External Objects

OData and custom adapters support writes. Practical constraints:

  • No DML callouts from triggers that touch External Objects (complicated execution context).
  • Write operations go through the source’s endpoints — latency and reliability mirror those endpoints.
  • Cross-object operations (workflow rules, flows) involving External Objects need careful testing.

For write-heavy use cases, data replication is often simpler than Salesforce Connect.

Governor Limits

External Object queries have their own limits:

  • Up to 20,000 records per query (OData/custom).
  • Up to 100 callouts per transaction (shared with other callouts).
  • Per-row overhead makes bulk operations slower than native objects.

Planning matters. If you have a Flow processing 200 records and each triggers an External Object lookup, that’s 200 callouts — tight against the limit.

Licensing

Salesforce Connect is not free. Pricing is by user or by calls, depending on edition. Verify with your AE before assuming availability.

For small use cases, per-call pricing can be economical. For high-volume, per-user often wins.

Indirect Lookups

External Objects can relate to Salesforce objects via:

  • External Lookup: the Salesforce field references the External Object’s external ID.
  • Indirect Lookup: the External Object’s field references a Salesforce standard/custom object’s external ID.

Indirect lookups let you pull Salesforce records into External Object related lists without making them appear to “live” in the external system.

Anti-Patterns

Virtualizing high-volume transactional data. Orders created thousands per day, queried every minute by many users — the source will buckle.

Skipping auth testing at scale. Single-user testing passes; 500 concurrent users with per-user OAuth tokens reveal refresh storms.

Ignoring failure modes. Source goes down → Salesforce shows errors. Design UI degradation gracefully.

Using External Objects for reporting joins. Reports joining native and External Objects are often painful. Consider a Data Cloud or warehouse federation instead.

Frequently Asked Questions

Can External Objects be queried with SOQL?

Yes, but the SOQL subset is narrower than on native objects. Complex queries may not push down filter logic cleanly.

Do External Objects work in Flow?

Yes — Get Records, Create Records, Update Records, and Delete Records all support External Objects.

Can I have triggers on External Objects?

Yes, but limited. Apex triggers on External Objects run when the objects are accessed — not on source-system changes. The source must notify Salesforce separately for that.

Is Salesforce Connect replaced by Data Cloud?

Not replaced, but Data Cloud’s zero-copy federation addresses similar problems for CRM/CDP use cases. For simpler operational virtualization, Salesforce Connect is still the right tool.

Share