Salesforce Connect and External Objects

Why Salesforce Connect and External Objects Matter

Modern organizations rarely keep all their data in one system. Order history may live in SAP, inventory in an Oracle database, billing details in a legacy ERP, and customer records in a second Salesforce org. Users still need to see all of that information in a single place while working an account, case, or opportunity. Traditionally the answer was to copy the data into Salesforce with ETL tools or Data Loader, which creates duplicate data, consumes expensive data storage, introduces latency, and raises the question of which system is the system of record.

Salesforce Connect solves this through data virtualization: the data stays where it is, and Salesforce displays it in real time as though it were a native object. For the Advanced Administrator exam, this topic sits in the Advanced Data and Analytics Management domain. You are expected to recognize when Salesforce Connect is the right solution, understand its components and relationship types, and know its limitations compared with importing data. Expect scenario questions where the deciding clue is whether the business wants the data stored in Salesforce or merely visible from Salesforce.

What Salesforce Connect Is

Salesforce Connect is an integration feature (formerly called Lightning Connect) that lets you access data stored outside your org without copying it into Salesforce. Instead of physical records, Salesforce maps to tables in the external system and retrieves rows on demand each time a user views a list, record page, or related list.

The key building blocks are:

1. External Data Source - The definition of the connection. It specifies the adapter type, the endpoint URL, authentication settings (anonymous, per-user, or named principal), and options such as whether the data is writable or whether the source is high data volume.

2. External Objects - Objects that map to tables in the external data source. They behave much like custom objects: you can add them to the app navigation, create list views, build record pages with Lightning App Builder, add them as related lists, and search them. The API name of an external object ends in __x (versus __c for custom objects). You can create external objects manually or let Salesforce generate them with Validate and Sync on the external data source.

3. External Object Fields - Fields that map to columns in the external table. The External ID field is the unique identifier from the external system and is critical for relationships. Supported field types are limited (text, text area, number, percent, checkbox, date, date/time, email, phone, URL, and the relationship field types). Formula, roll-up summary, and master-detail fields are not supported.

The Adapters

The adapter determines how Salesforce talks to the external system:

OData 2.0 and OData 4.0 adapters - Open Data Protocol is a REST-based standard supported by many databases and middleware products. This is the most common adapter and supports read and write access.

Cross-Org adapter - Connects to another Salesforce org using the Lightning Platform REST API. Ideal for companies with multiple orgs that need to see each other's data without a complex integration. Only the subscribing org needs the Salesforce Connect license; the provider org simply needs API access, and callouts count against the provider org's API limits.

Custom adapter (Apex Connector Framework) - When the external system does not speak OData, a developer can build a custom adapter in Apex to connect to virtually any REST API or data format. Recognize this on the exam when a question mentions a proprietary API or a format that is not OData.

Newer adapters such as the Amazon Athena adapter and GraphQL adapter also exist, but exam scenarios overwhelmingly focus on OData, Cross-Org, and custom Apex adapters.

How It Works End to End

1. An administrator creates an External Data Source, chooses the adapter, enters the URL, and selects the identity type.
2. The admin clicks Validate and Sync, which queries the external schema and lists available tables. Selecting tables generates external objects and their fields automatically.
3. The admin configures relationships between external objects and standard or custom objects so the external data appears in related lists.
4. Profiles or permission sets grant object permissions and field-level security on the external objects, and the objects are added to apps and page layouts.
5. When a user opens a record, Salesforce makes a callout to the external system, retrieves the matching rows, and renders them. Nothing is stored in Salesforce (aside from temporary record IDs that Salesforce assigns to each external row during the session).

Authentication Options

Anonymous - No credentials; appropriate only for public or internal unprotected endpoints.
Named Principal - A single set of credentials is used for everyone. Simple, but every user sees the same data regardless of their rights in the external system.
Per User - Each user authenticates with their own credentials (set in their personal settings or through an authentication provider). The external system can enforce its own row-level security. Choose this when the question stresses that users should see only the external data they are entitled to.

Relationship Types - The Most Tested Topic

Three relationship fields connect external objects to the rest of your data model. Memorize which direction each one runs and what the matching key is:

Lookup relationship - The child is an external object and the parent is a standard or custom Salesforce object. The external table must contain a column holding the 18-character Salesforce record ID of the parent. Use this when the external system already stores Salesforce IDs.

External lookup relationship - The parent is an external object. The child can be a standard, custom, or another external object. The relationship matches on the parent external object's External ID field. Use this when Salesforce records (for example Cases) need to point to records that live in the external system (for example Products in an ERP).

Indirect lookup relationship - The parent is a standard or custom Salesforce object and the child is an external object, but the external system does not know Salesforce IDs. Instead, the match is made on a custom field on the parent that is marked Unique and External ID (for example an ERP Customer Number on Account). This is the most common real-world and exam scenario: showing external orders on an Account related list by matching the ERP customer number.

Quick memory aid: Lookup = Salesforce ID in the external table; Indirect = external key stored on the Salesforce parent; External lookup = the parent itself is external.

Capabilities and Limitations

Supported: tabs, list views, record pages, related lists, global search (if the data source is marked searchable), record detail in the Salesforce mobile app, writable records (create, edit, delete) for OData and Cross-Org adapters when the data source is marked writable, use in reports in a limited way (external objects can be a primary object or joined through lookups, though with performance and row limits), SOQL and SOSL queries from Apex, and Lightning App Builder components.

Not supported or limited: master-detail relationships, roll-up summary fields, formula fields, record types, Chatter feed tracking, validation rules, workflow rules, approval processes, record-triggered flows and Apex triggers on external objects, sharing rules and record-level sharing (access is governed by object permissions, field-level security, and the external system's own security when using per-user authentication), field history tracking, and Data Loader or import of external records (since there is nothing to import).

Governor-style limits to recognize: an org can have up to 100 external objects (this does not count against the custom object limit), and OData callouts are rate limited per hour (commonly cited as 20,000 per hour in Enterprise, Performance, and Unlimited editions). Enabling the High Data Volume option on a data source raises scalability for very large tables but turns off features such as retaining record IDs across sessions, reports, and some relationship behaviors. Salesforce Connect is a paid add-on license for most editions and is included free in Developer Edition, which is why many questions mention licensing cost as a consideration.

Salesforce Connect Versus Other Integration Options

Data Loader or ETL (Informatica, MuleSoft, Jitterbit) - Physically copies data into Salesforce. Choose this when you need roll-up summaries, triggers, full reporting, sharing rules, or offline availability, and when storage and data freshness are acceptable trade-offs.
External Services - Registers a REST API so its operations become invocable actions in Flow. It is for calling actions, not for displaying tables of data as objects.
Heroku Connect - Bi-directionally syncs Salesforce data to a Postgres database; the opposite direction of the problem Salesforce Connect solves.
Canvas apps or iframes - Embed an external user interface; the data is not queryable or related to Salesforce objects.
Salesforce Connect - Choose when the requirement includes phrases such as real time, without copying or storing, reduce data storage, external system remains the system of record, view in a related list, or data changes frequently.

Exam Tips: Answering Questions on Salesforce Connect and External Objects

Tip 1 - Hunt for the storage clue. If the scenario says the company does not want to store, duplicate, or consume storage for external data, or wants to see live data, the answer is Salesforce Connect with external objects. If the scenario needs roll-ups, triggers, approval processes, or complex reporting on that data, the answer is to import or sync the data instead.

Tip 2 - Match the adapter to the source. Another Salesforce org means the Cross-Org adapter. A database, SAP, or middleware exposing OData means the OData 2.0 or 4.0 adapter. A proprietary or non-OData REST API means a custom adapter built with the Apex Connector Framework.

Tip 3 - Know the relationship decision tree cold. Ask two questions: Which object is the parent? What key does the external system hold? External parent means External Lookup. Salesforce parent with Salesforce IDs in the external table means Lookup. Salesforce parent matched on an External ID/Unique custom field means Indirect Lookup. A scenario about showing ERP orders on Accounts using a customer number almost always points to Indirect Lookup.

Tip 4 - Remember what you cannot do. Eliminate answers that propose roll-up summary fields, master-detail relationships, formula fields, triggers, workflow, validation rules, record types, or sharing rules on external objects. These distractors appear frequently.

Tip 5 - Recognize the __x suffix. If an answer choice or field name shows an object ending in __x, it is an external object. This can quickly confirm which objects in a scenario are virtual.

Tip 6 - Think about authentication when the question mentions user-specific access. Named Principal gives everyone the same view; Per User enforces the external system's row-level security per individual. If the requirement says each user should see only the records they are authorized for in the external system, choose per-user authentication.

Tip 7 - Validate and Sync is the admin shortcut. When asked for the fastest or least-effort way to create external objects and fields, the answer is Validate and Sync on the external data source rather than manually creating each object.

Tip 8 - Consider licensing and limits as tie-breakers. Salesforce Connect is an add-on cost and has a cap of 100 external objects plus hourly callout limits. If a question stresses a very small, static dataset or an extremely high transaction volume where every page view would hammer the external system, an import or scheduled sync may be the better recommendation. Conversely, if the external dataset is enormous and would blow through Salesforce storage, Connect (possibly with the High Data Volume option) is the better fit.

Tip 9 - Separate Salesforce Connect from External Services. External Services is about invoking REST actions in Flow; Salesforce Connect is about surfacing external tables as objects. Questions that mention Flow actions or invoking an API operation point to External Services; questions about tabs, list views, and related lists point to Salesforce Connect.

Tip 10 - Read for the words 'real time' and 'system of record.' These two phrases are the strongest signals in the exam that the correct architecture keeps the data external and virtualizes it with Salesforce Connect.

Summary

Salesforce Connect lets administrators surface external data inside Salesforce in real time without copying it, using external data sources, adapters (OData, Cross-Org, or custom Apex), and external objects identified by the __x suffix. The three relationship types - lookup, external lookup, and indirect lookup - determine how external data ties to Salesforce records, and the limitations around automation, roll-ups, and sharing define when it is and is not the right tool. Master the decision clues, the relationship logic, and the capability boundaries, and you will handle every Salesforce Connect question on the Advanced Administrator exam with confidence.