External Data

Not all data belongs inside Salesforce. A CTA must know when to bring data onto the platform, when to leave it external, and how to bridge the two. This decision affects storage costs, performance, integration complexity, and user experience.

The Fundamental Question

Before designing any data architecture, ask: Should this data live in Salesforce?

Figure 1. The first question for any external data source is whether users actually need it in Salesforce at all. Volume, freshness requirements, and system-of-record ownership together determine whether to replicate via ETL, virtualize with Salesforce Connect, or route analytics through Data Cloud.

Salesforce Connect

Salesforce Connect provides real-time access to external data through External Objects, without copying data into Salesforce.

How It Works

Figure 2. Every time a user views a related list or report containing external object data, a live callout fires through the OData adapter to the external system. There is no caching by default, so response time is directly dependent on the external system’s performance and network latency.

Adapters

Adapter	Connects To	Best For
OData 2.0	Any OData 2.0 endpoint	SAP, Microsoft Dynamics, custom APIs
OData 4.0	Any OData 4.0 endpoint	Modern REST APIs with OData support
Cross-org	Another Salesforce org	Multi-org architectures
Custom (Apex)	Any system via Apex	Systems without OData support

Adapter Architecture Comparison

Each adapter type has a different data flow path. Understanding these paths is critical for latency analysis and troubleshooting.

Figure 3. The three adapter types differ in translation overhead and flexibility. The OData adapter requires the external system to expose an OData endpoint. The Cross-Org adapter skips translation entirely by calling Salesforce REST APIs natively. The Custom Apex adapter provides maximum flexibility but requires Apex development and testing for each target system.

Latency differences

OData adds translation overhead (Salesforce-to-OData-to-native query). The Cross-Org adapter is faster for connecting two Salesforce orgs because it uses the native REST API with no translation layer. Custom adapters have the most flexibility but require Apex development and testing for each external system.

Cross-Org Adapter

The cross-org adapter is especially relevant for CTA scenarios involving multi-org strategies:

Connects two Salesforce orgs without middleware
Uses standard Salesforce APIs under the hood
Supports SOQL-like queries across orgs
Subject to API limits on both orgs
Useful for franchise models, acquisitions, or multi-cloud architectures

Salesforce Connect Limits

Limit	Value
External objects per org	100
Rows returned per query	2,000 (page-based)
Named credentials	50 per org
Callout time limit	120 seconds
Monthly callout limit	Based on license type

User experience impact

External objects add latency to every page load and related list render. Users accustomed to sub-second Salesforce response times will notice 1-3 second delays for external data. Set expectations and consider caching strategies.

External Objects Deep Dive

External objects (__x suffix) represent data stored outside Salesforce.

Capabilities and Limitations

Feature	Supported?	Notes
Related lists	Yes	Appear on parent records
List views	Yes	With filter limitations
SOQL	Partial	Subset of operators, no aggregate queries
SOSL (search)	Limited	Supported with restrictions - only text fields searchable, must be enabled on the data source, specific syntax limitations apply
Triggers	Limited	Via Change Data Capture change event triggers only (asynchronous, after-commit)
Flows	Limited	Some actions supported
Reports	Limited	Can be included in custom report types
Validation rules	No	Validation must happen in external system
Workflow rules	No	Use triggers or flows instead
Approval processes	No	Not supported

Relationship Types for External Objects

Relationship	Description
External lookup	Standard/custom object looks up to external object (by External ID)
Lookup	External object looks up to standard/custom object (by 18-char Salesforce ID)
Indirect lookup	External object looks up to standard/custom object (by unique external ID field)

Indirect lookups are key

Indirect lookups let you relate external objects to Salesforce objects without the external system knowing Salesforce IDs. The external system uses its own ID, and Salesforce matches it against a unique external ID field on the parent object. This is the recommended approach for most scenarios.

Big Objects

Big Objects (__b suffix) store massive volumes of data on the Salesforce platform itself. They keep data within the platform’s trust boundary.

When to Use Big Objects

Scenario	Why Big Objects
Audit trail archival	Store field history beyond 18-month limit
Historical transactions	Transaction logs, payment history, event logs
IoT telemetry	Sensor data, device events
Regulatory compliance	Long-term record retention on-platform
LDV archival	Move aged records from standard objects

Big Object Constraints

Constraint	Detail
Query	Standard SOQL on indexed fields only; Async SOQL was retired (Summer 2023) — use Batch Apex or Bulk API
DML	`Database.insertImmediate()` - no standard insert/update
Index	Defined at creation, immutable after
Triggers	Not supported
Reports	Not supported directly (query results into custom objects)
Relationships	Can have lookups but cannot be child in master-detail
Storage	Counts toward Big Object storage, not data storage

Big Objects vs Custom Objects

Choosing between Big Objects and standard Custom Objects is a critical architectural decision. The diagram below highlights the key differentiators.

Figure 4. Big Objects trade rich query capability for massive scale. Below 10M records, Custom Objects provide triggers, reporting, and full SOQL, so choose them unless the use case is specifically audit or archival. Beyond 1B records, Big Objects or external storage are the only viable on-platform options.

Capability	Custom Object	Big Object
Record scale	Millions (with LDV tuning)	Billions
SOQL	Full SOQL support	Standard SOQL on indexed fields only; Async SOQL was retired (Summer 2023) — use Batch Apex or Bulk API
DML	Standard insert/update/delete	`Database.insertImmediate()` only
Triggers	Full support	Not supported
Reporting	Full support	Not supported (query into custom objects)
Index changes	Configurable anytime	Immutable after creation
Storage type	Counts toward data storage	Separate Big Object storage
Use case	Operational data	Archival, audit, telemetry, historical

Big Object Index Design

Big Object indexes are defined at creation and cannot be changed. This makes upfront design critical.

Index fields define query capability (you can only query by index fields)
First index field is the most significant (leftmost in the composite key)
Index determines sort order of results
Maximum 5 fields in the index

Immutable indexes

If you get the Big Object index wrong, you must delete the Big Object and recreate it. All data is lost. Design the index based on how you will query the data, not how you will insert it.

Data Cloud (now Data 360)

Salesforce Data Cloud (now Data 360 as of the October 2025 rebrand; formerly CDP, formerly Salesforce 360 Audiences) is the platform’s answer to unified data management at scale.

Data Cloud Capabilities

Capability	Description
Data ingestion	Ingest from Salesforce CRM, external databases, cloud storage, streaming
Identity resolution	Unify customer profiles across sources
Segmentation	Create audiences based on unified data
Activation	Push segments to marketing channels, CRM, or external systems
Analytics	Query large datasets without platform limits
Calculated insights	Computed metrics available in Salesforce records

Data Cloud Architecture Pipeline

Data Cloud processes data through a defined pipeline: ingest, unify, analyze, and activate. Each stage transforms raw data into actionable customer insights.

Figure 5. Data Cloud’s four-stage pipeline distinguishes it from traditional ETL: identity resolution in the Unify stage merges the same customer across all source systems into a single Unified Profile before analysis begins, enabling segmentation and activation based on a complete cross-channel customer view.

Architectural details:

Storage Native Change Events (SNCE) notify when data changes; Change Data Feed (CDF) identifies what changed, making the platform reactive rather than polling-based
Identity resolution uses matching rules (exact and fuzzy) and reconciliation rules to merge duplicate profiles. Near-real-time pipelines target sub-five-minute turnaround
Calculated insights define aggregated metrics (e.g., lifetime value, engagement score) that can be surfaced on CRM records
Activation pushes segments and insights to any downstream channel: Marketing Cloud journeys, ad platforms, CRM flows, or external systems

When Data Cloud vs Traditional Integration

Factor	Data Cloud	Traditional ETL/Integration
Primary goal	Unified customer view, analytics	Transactional data sync
Data volume	Billions of records	Millions of records
Latency	Near real-time (minutes)	Real-time (seconds) to batch
Query model	SQL-like on data lake	SOQL on platform objects
Cost	Separate Data Cloud license	Integration tool license
Complexity	Data model mapping, identity rules	Field mapping, error handling

Data Virtualization vs Replication

This is a core architectural decision that a CTA must articulate clearly.

Comparison

Dimension	Virtualization (Salesforce Connect)	Replication (ETL/API Sync)
Data freshness	Real-time (live query)	Depends on sync frequency
Performance	Slower (external callout per query)	Faster (local data)
Storage cost	No Salesforce storage consumed	Consumes Salesforce data storage
Offline access	Not available	Available
SOQL support	Limited subset	Full SOQL
Reporting	Limited	Full reporting
Trigger/Flow support	Minimal	Full support
Complexity	Lower (no sync logic)	Higher (sync, conflict resolution)
Availability	Dependent on external system uptime	Independent of external system

Decision Flowchart

Figure 6. Write access is the first fork: virtualization via Salesforce Connect is read-only by design. Reporting requirements and volume determine whether to replicate or route analytics through Data Cloud. Real-time freshness without write access is the clearest case for Salesforce Connect External Objects.

Hybrid Patterns

Most enterprise architectures combine multiple approaches:

Pattern 1: Core + Extended

Core data (Accounts, Contacts, Opportunities) - replicated in Salesforce
Extended data (transaction history, audit logs) - external via Connect or Big Objects
Analytics data (clickstream, IoT) - Data Cloud or external data warehouse

Pattern 2: Warm + Cold Storage

Warm data (recent, actively accessed): Salesforce standard objects
Cold data (aged, infrequently accessed): Big Objects or external storage
Archival: External data lake with Salesforce Connect for occasional access

Pattern 3: System of Record + Reference

System of record data: mastered and stored in Salesforce
Reference data (product catalogs, pricing from ERP) - virtualized via Connect
Enrichment data (firmographics, credit scores) - periodic batch sync

CTA Scenario Considerations

When evaluating external data in a CTA scenario, address these questions:

Who is the system of record? Where is each entity mastered?
What is the access pattern? Read-only reference or interactive read-write?
What is the acceptable latency? Sub-second or minutes?
What is the data volume? Hundreds, thousands, or millions of records?
What reporting is needed? Standard reports or just inline visibility?
What is the availability requirement? Can the solution tolerate external system downtime?
What are the licensing implications? Salesforce Connect licenses, Data Cloud licenses?

Integration Patterns: external data access is an integration pattern; Salesforce Connect uses callout-based access
Sharing Model: external data must respect org sharing model and Named Credentials
Large Data Volumes: external storage and Big Objects are LDV archival strategies
Data Modeling: external objects use different relationship types (external lookup, indirect lookup)
Org Strategy: multi-org architectures with cross-org adapter affect org strategy decisions
Data Cloud Architecture: Data Cloud provides an alternative to Salesforce Connect for large-scale external data

Sources

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.