We are at Dreamforce 2026, Industry Pavilion at San Francisco
February 11, 2026
There are six ways to extract data from Salesforce Data Cloud: data shares for zero-copy access from Snowflake or Databricks, activations for segment exports to S3 and marketing platforms, SQL query APIs for programmatic pulls, data actions for real-time event pushes, triggered flows for no-code callouts, and the MuleSoft connector for orchestrated integration. Data Loader does not work here, because Data Cloud runs on a lakehouse rather than standard CRM objects.
Which one you pick depends on three things: how fresh the data needs to be, where it is going, and who is building it. This guide walks through each method, the setup steps for the three most common ones, what extraction costs you in credits, and how to tell when a scheduled export has quietly stopped running.
Salesforce rebranded Data Cloud to Data 360 on October 14, 2025. The product is the same, and Salesforce's own documentation still shows both names during the transition.
You will see this reflected in the tooling. The APIs are now branded Data 360 Connect, and flow automation appears as Data 360-Triggered Flows. If you are searching for guidance and getting thin results, try both names. Older material uses Data Cloud, newer material uses Data 360, and plenty of community write-ups mix them. This guide uses both for the same reason.
Start here before you configure anything. Picking the wrong extraction path is the most common reason these projects get rebuilt.
Notice that only two of the six are genuinely admin-friendly. Budget for engineering time on the rest. Community rundowns such as those on SFDC Fanboy are useful for seeing how teams combine several of these in one architecture.
Match the destination to the mechanism. Most teams overcomplicate this by starting with the API.
Data shares are the strongest option when your analytics already live in a supported cloud warehouse. Nothing is copied. Your warehouse queries the data where it sits.
The flow is short, and most of the work is on the partner platform side.
From there your analysts query it like any other table. No pipeline to schedule, no files to reconcile.
Zero-copy gets described as the obvious best choice. It is excellent, but it has real trade-offs worth knowing before you commit an architecture to it.
Queries run against Data 360, so a heavy dashboard hitting the share repeatedly consumes platform capacity rather than your warehouse's. Performance depends on how your DMOs are modeled, not just on your warehouse cluster size. And the option only exists for supported partner platforms, so a self-hosted or unsupported warehouse rules it out entirely.
Test with a realistic query load before you retire an existing pipeline. Introductory walkthroughs on Salesforce Tutorial are a reasonable starting point if your team is new to the object model.
Activations are the right tool when data needs to land somewhere as records or files: an S3 bucket, an SFTP server, Marketing Cloud, or an ad platform.
Targets are the destination definition, and you build them once.
Activations publish segments, not raw tables. That is the part teams miss when they expect a full table dump.
Open the Segments tab, create a new segment, and filter your Unified Individual or other DMOs with the visual builder. Keep the segment as narrow as the use case allows, because segment size drives both runtime and cost.
Now define the payload and the cadence.
If the destination is a marketing platform, coordinate the attribute list with whoever owns campaign logic there. Aligning this with your Marketing Cloud personalization setup avoids exporting fields nobody uses.
This is the option the original version of most guides skips, and it is often the simplest answer for analysts and developers.
Data 360 supports SQL. You can query DMOs from the query editor in the UI for ad hoc work, or programmatically through the Data 360 Connect API for anything repeatable.
A practical tip on volume. These APIs are built for querying, not for bulk dumping billions of rows. If you find yourself paginating through an enormous result set on a schedule, that is a signal you wanted a data share or an activation instead.
Salesforce's own Salesforce Developers documentation is the authoritative reference for the current API surface, which is still changing as the Data 360 rename rolls through. Wiring any of these into a wider system is standard integration architecture work rather than a configuration task.
When hours of latency will not do, you need something that fires on change rather than on a schedule.
Data actions watch a data model object or calculated insight and push a JSON payload when a condition is met. The target can be a webhook, a platform event, or Marketing Cloud. This is how you get a Slack alert the moment a high-value customer crosses a threshold.
Data 360-triggered flows do something similar without code. A change in a calculated insight starts a flow, and an HTTP callout action sends the payload onward. Admins can build and maintain these, which matters more than it sounds when the person who wrote the integration leaves.
Both paths shine when downstream systems need to react rather than report. That includes AI agents, which need current context to act on. If Agentforce is on your roadmap, real-time extraction paths are what feed it. Developer-focused breakdowns on SFDCPanther are handy when you get to payload and authentication details.
Almost nobody plans for this, and it is the item most likely to surprise your finance team in month three. Data 360 consumption is metered, and extraction is not free.
The pattern is consistent. Frequency and breadth drive cost, and both are usually set once by whoever built the first version and never revisited. Put a quarterly review on the calendar.
Scheduled exports fail quietly. The dashboard keeps showing yesterday's numbers, and nobody notices until someone questions a report.
The common thread is that most extraction failures are not extraction failures. They are ingestion or identity resolution problems showing up at the exit. Check upstream before you rebuild the export.
Every extraction path is also a path for personal data to leave a governed environment. That deserves a decision, not a default.
Keep three habits. Export the minimum set of attributes the destination actually needs, rather than everything convenient. Use data spaces to separate regulated data from general analytics so the wrong segment cannot reach the wrong target. And keep a register of every active extraction, its destination, its owner, and what personal data it carries.
That register is what makes a subject access request or a GDPR audit answerable in an afternoon instead of a fortnight. Treating it as part of ongoing Salesforce administration keeps it current rather than reconstructed under pressure.
No. Data Loader works against standard CRM objects, and Data Cloud stores data in data model objects on a lakehouse architecture at far greater scale. Use data shares, activations, or the query APIs instead.
Yes. Salesforce rebranded Data Cloud to Data 360 on October 14, 2025. You will still see both names in the product and the documentation while the transition completes.
A data share lets a supported platform such as Snowflake or Databricks query your Data 360 data where it lives, with no replication or ETL pipeline. You avoid copy costs, but queries consume Data 360 capacity rather than your warehouse's.
Create an Amazon S3 activation target, build a segment for the records you want, map the attributes the destination needs, then set a publish schedule. Data 360 writes files to the bucket on that cadence.
Yes. Use the query editor in the UI for ad hoc analysis, or the Data 360 Connect API for programmatic SQL. JDBC, Python, and Power BI connectors are also available for direct client access.
Data actions and Data 360-triggered flows both fire on change rather than on a schedule, which makes them the right choice for alerts, webhooks, and anything feeding an AI agent that needs current context.
Extraction from Data 360 is less about tooling than about picking correctly the first time. Data shares for analytics, activations for files and audiences, query APIs for applications, and event-driven paths for anything that has to happen now.
Get that choice right and the rest is configuration. Get it wrong and you rebuild in six months, having paid credits for the privilege. At Minuscule Technologies we architect these paths deliberately: the right mechanism per destination, cost modeled before build, and a governance register that survives an audit. Talk to our Salesforce engineering team about your Data 360 extraction architecture before you wire the first pipeline.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
