Salesforce Data Cloud Integrations: How They Work in 2026

Salesforce Data Cloud integrations can connect your CRM to warehouses, cloud storage, marketing platforms, advertising systems, and external applications. But “does Salesforce integrate with X?” is only the first question. The more important one is how the connection works, what happens to the data after it arrives, and what you pay to process it.

This guide breaks down the current Data 360 integration architecture, including connectors, zero-copy federation, APIs, and activation. It also covers common tools for RevOps stacks such as Snowflake, Amazon S3, HubSpot, Google Ads, and LinkedIn Ads, then looks at when an enterprise CDP is more infrastructure than a GTM team actually needs.

What Salesforce Data Cloud integrations are

Data 360 sits between your systems of record and your systems of action, holding a unified profile in the middle. So, a Salesforce Data 360 integration does three things:

1. First, it connects a source and brings data into Data 360 or makes external data queryable through zero-copy federation
2. Second, the data can be prepared and mapped to Salesforce’s Customer 360 Data Model, then unified through identity resolution
3. Third, the resulting data can be queried, segmented, activated, or shared with external destinations

For RevOps teams, Data 360 tries to solve the fragmentation problem that shows up when CRM data goes stale across systems and no single tool has the full story. It's a CDP, a data lake, and an activation engine bundled into one Salesforce-native layer (with all the strengths and trade-offs that bundling implies).

How Data Cloud connects to other systems

Data 360 supports four connection methods. The easiest way to understand Salesforce Data Cloud connectors is to separate them by what happens to the data.

Method #1: Prebuilt connectors

Prebuilt connectors are the lowest-friction option when Salesforce already supports the system you need. The connector handles authentication and the connection to the source, after which you create a data stream and map the source fields into Data 360.

The current Data 360 connector catalog covers CRM, marketing, advertising, databases, cloud storage, commerce, and other systems. Salesforce's directory lists each connector's direction, data type, and supported connection method. So, you can easily check whether a connector exists and whether it supports the direction and method your use case requires.

Best for: Standard sources where you want a supported integration without building and maintaining a custom pipeline.

Method #2: Zero-copy federation

Zero-copy federation lets Data 360 access data in an external system without first copying the underlying dataset into Data 360.

Zero-copy includes three modes:

• Query federation: Data 360 sends SQL to the external engine, which returns results
• File federation: Data 360 reads Apache Iceberg tables directly at the storage layer, bypassing external compute
• Data sharing: External systems expose governed objects for in-place querying

Snowflake, for example, supports zero-copy connections through all three. Zero-copy today also works with Databricks, Google BigQuery, Amazon Redshift, and Iceberg-based lakes.

This method is useful when your data warehouse remains the system of record and duplicating large datasets would add unnecessary storage, movement, or synchronization work.

It doesn’t mean there’s no setup involved, though. Permissions, authentication, network access, primary keys, supported data types, and query behavior still need to be configured.

Best for: Teams with mature warehouse infrastructure that already treat it as their source of truth and want to avoid double storage and sync lag.

Method #3: Ingestion APIs and custom connections

When there’s no suitable prebuilt connector, Data 360 can ingest data through APIs and custom integration mechanisms. It supports three ingestion frequencies:

• Real-time: Sub-second via Ingestion APIs with Change Data Capture (CDC)
• Streaming: Micro-batch every 1–3 minutes via native connectors
• Batch: Scheduled large-volume loads via connectors or APIs

This gives you more control over the shape and timing of incoming data, but shifts more responsibility onto the implementation team.

This approach is useful for proprietary applications, internal databases, or data sources where the standard connector doesn’t expose the objects or fields you need.

Best for: Custom applications and specialized data sources where standard connectors are insufficient.

Method #4: Activation targets

Not every integration is about getting data into Data 360. Activation targets send segments or other outputs from Data 360 into external systems.

Google Ads, for example, has a Data 360 activation connector that uses incremental updates and a direct API. LinkedIn similarly supports activation to LinkedIn Campaign Manager, alongside connectors that bring advertising data into Data 360.

This creates a two-directional pattern: ingest data, unify it, build a segment, then send that segment somewhere else.

Best for: Marketing activation, audience management, and workflows where unified data needs to reach an external channel.

Key Data Cloud integration categories for RevOps and what they cover

This is roughly how a typical Salesforce Data Cloud architecture ends up looking for a mid-market or enterprise GTM team:

What Data Cloud integrations cost to run

Data 360 uses a consumption-based credit model, and integrations are where credits get spent. Every ingestion, identity resolution run, segmentation refresh, and activation event draws from a credit balance.

(All figures below are from Salesforce's official pricing page, verified August 2026.)

Salesforce says bringing data into Data 360 is free, while consumption occurs when customers use Data 360 actions such as preparation, unification, segmentation, activation, and other processing. Salesforce also offers a free provision for existing customers with limited credits and storage.

The catch is that volume and usage pattern matter. Salesforce's official rate card applies different multipliers to activities such as preparation, unification, segmentation, activation, queries, and zero-copy sharing.

Credits are also consumed differently across production vs. sandbox and batch vs. streaming.

Salesforce Data 360 credit consumption rate sheet

Implementation also has an operational cost. It’s helpful to analyze existing data sources, define a data strategy, understand billing implications, plan unified profiles, and establish the required permissions before you implement Data 360.

That planning isn’t bureaucracy for its own sake. As per Gartner's research, 44% of sales leaders cited poor data quality as a barrier to analytics success, alongside privacy concerns and limited cross-functional collaboration. The consequence for RevOps is straightforward: connecting more data doesn’t automatically produce more useful data.

When Data Cloud integrations are more than you need

Data 360 makes sense when you have a genuinely enterprise-scale customer data problem: multiple systems, complex identity resolution, large datasets, sophisticated segmentation, analytics requirements, and activation across Salesforce and external channels.

But there is another common requirement we come across from GTM teams: “We need one clean GTM data layer that my revenue systems and agents can actually use.”

Because in its absence, leads sit too long, records aren't enriched before routing, qualification lives across five tools, and the "single source of truth" everyone keeps promising never materializes where reps actually work.

A warehouse or CDP can consolidate records without necessarily becoming the operational layer for routing, enrichment, scheduling, and GTM workflows. That distinction becomes more important as teams start deploying AI agents.

A lightweight alternative to Data Cloud integrations

To fill this gap, we’ve (re)built Default as the AI infrastructure layer for GTM teams.

Default now runs a warehouse-native revenue data layer. It connects your CRM, website, forms, enrichment vendors, ad platforms, product data, and other GTM sources into a unified, identity-resolved data layer.

On top of that layer sit GTM tools such as enrichment, routing, workflows, and scheduling, which can be used by both people and agents.

How to plan a Data Cloud integration rollout

A successful rollout starts with the use case rather than the connector. Before connecting every available source, decide what the data needs to do once it arrives.

Step #1: Audit the data sources and define the use cases

List the systems that contain useful customer and prospect data. They will likely include your CRM, marketing automation, warehouse, product analytics, enrichment providers, advertising platforms, and other operational systems.

For each source, define the job the data needs to perform. Is it contributing to identity resolution, reporting, segmentation, enrichment, routing, activation, or AI?

Outcome: A one-page map of sources, destinations, and the business decisions each one informs.

Step #2: Choose the right connection method for each source: ingestion, federation or activation

Next, decide how each source should connect.

Use:

• Batch ingestion when Data 360 needs its own copy of the data
• Zero-copy federation when the external system should remain the source of truth
• Activation when the important action happens outside Data 360

A team with an established warehouse may prefer federation over moving another copy of its data into a CDP.

Outcome: A connector plan with cost and effort scored for every source.

Step #3: Design identity resolution and field mapping

Getting records into Data 360 is only the beginning. Source schemas need to be mapped to the Customer 360 Data Model, and you need to set up identity resolution rules for determining when records represent the same person or entity.

Before production rollout, validate representative records across systems. Test duplicates, conflicting fields, missing identifiers, and account-person relationships. If the unified profile is wrong, every downstream segment, report, workflow, or agent that depends on it inherits the problem.

Outcome: A documented identity model with match rules validated on real records.

Step #4: Start with one operational outcome

Don't connect every source and activate every possible feature on day one. Pick one measurable outcome, such as scoring leads, building a unified account view, creating an audience, improving campaign reporting, or feeding a qualification signal into a GTM workflow.

Then measure data freshness, match quality, processing volume, downstream usage, and business impact before expanding.

Here’s a simple readiness check:

• Each source has a defined purpose
• Source-of-truth ownership is documented
• The integration method matches the use case
• Identity resolution has been tested on representative records
• Data processing and credit consumption are understood
• Someone owns monitoring and maintenance
• There is a defined operational outcome beyond “the data is connected.”

Unify your GTM data without the heavy lift using Default

Data 360 remains the right call for enterprise analytics and cross-cloud personalization at scale. But if what you actually need is clean unified data feeding routing, enrichment, and workflow execution—without a six-month implementation and a credit-consumption dashboard—a purpose-built revenue data layer gets you there faster.

As a Data Cloud alternative, Default brings CRM, marketing, website, enrichment, advertising, and other revenue data into one identity-resolved model. It then puts routing, enrichment, workflows, scheduling, and agents on top of it. Dot can query that shared context and turn plain-language requests into working GTM systems, with human approval and auditability built into the agent workflow.

FAQs

1. Which Salesforce editions include Data Cloud?

It depends on the Salesforce product and edition combination you have. Data 360 is sold through specific SKUs and entitlements rather than being universally included with every Salesforce edition. Check Salesforce's current pricing and edition documentation before planning an implementation.

2. How do you enable Data Cloud in Salesforce?

You first provision Data 360 by contacting your Salesforce Account Executive. Then, configure connections, data streams, mappings, identity resolution and other capabilities through Data 360 Setup. Salesforce recommends defining your data strategy, sources, users and goals before starting configuration.

3. Is Salesforce Data Cloud the same as Data 360?

Yes. Salesforce renamed Data Cloud to Data 360 in 2025. The company says the functionality and content remained unchanged, although older documentation still uses the Data Cloud name.

4. Does Salesforce Data 360 support Snowflake?

Yes. You can sync data bidirectionally between Snowflake and Salesforce Data 360, with the zero-copy query federation, file federation, and data sharing methods. This lets teams connect warehouse data without relying solely on a conventional copy-and-sync architecture.

5. Can Salesforce Data 360 connect to HubSpot?

Yes, the Salesforce HubSpot connector is labeled as beta at the time of writing this post (Aug 2026). It supports batch ingestion and zero-copy query federation, so teams should verify current availability, supported objects and beta limitations before making it part of a production architecture.