A Data Cloud implementation, now marketed by Salesforce as Data 360, takes as long and costs as much as its drivers demand. The main ones are the number of sources, their data quality, identity resolution complexity and the number of activation targets. Consumption pricing then adds running cost, which rises with every streaming ingest, refresh and activation (batch ingestion and zero-copy are now free). A first phase built around one use case keeps both predictable.
What does a Data Cloud implementation involve?
It involves turning data from several systems into unified profiles that Salesforce apps, marketing and agents can act on. The work runs in phases, and each phase depends on the one before it.
Salesforce now calls the product Data 360, while many contracts and screens still say Data Cloud. They are the same platform. Still deciding whether you need it? Start with our guide to when you need Data Cloud, then our use cases guide. This article assumes you have decided and want to plan the work.
- Use-case definition: name the decision or action the first release will change, its owner and how success will be measured.
- Source inventory: list each system that feeds the use case, its owner, its identifiers, its refresh needs and how it will connect.
- Data profiling: check completeness, formats and duplicates in each source before mapping anything.
- Data model and mapping: map each data stream to standard data model objects, adding custom objects only where standard ones do not fit.
- Identity resolution: set match rules that decide which records are the same customer, and reconciliation rules that decide which value wins.
- Calculated insights and segments: define the metrics and audiences the use case needs, with written definitions the business has approved.
- Activation: publish profiles, insights or segments to where they are used, such as CRM records, marketing channels, flows or agents.
- Governance and monitoring: assign owners, map consent, and watch data freshness, errors and credit consumption after go-live.
Some phases overlap in practice. Profiling often sends a team back to the source inventory, and tuning identity resolution often exposes a mapping gap. Plan for at least one loop between those phases.
How long does a Data Cloud implementation take?
It takes as long as the drivers in scope require, so there is no honest standard duration. A single use case on a few well-understood sources moves quickly. A program spanning many sources, brands and activation targets takes much longer.
The calendar is usually set less by configuration than by decisions and data. Waiting for access to a source system, agreeing on a metric definition or fixing a source upstream can each take longer than the build itself. Any timeline quoted before sources have been profiled is an estimate on assumptions, and those assumptions should be written down.
How much does a Data Cloud implementation cost?
There are two separate costs: the one-time effort to design and build, and the ongoing consumption Salesforce bills as the platform runs. Both depend on the same drivers, so a small first scope keeps both down.
Implementation effort is mostly people's time: architecture, mapping, rule tuning, testing and change management. Licensing and consumption are a conversation with Salesforce and your account team, not your implementation partner. Good scoping considers both together, because a design choice can shift cost from one to the other.
What drives the timeline and cost?
A handful of drivers explain most of the difference between a short project and a long one. The table shows what pushes effort up and what brings it down.
| Driver | What increases effort | What reduces it |
|---|---|---|
| Number of sources | Many systems connected in the first release, each with its own owner and access process | Two or three sources chosen because the first use case needs them |
| Connection method | Sources with no prebuilt connector that need custom APIs or middleware | Prebuilt connectors, or zero-copy access to a warehouse the data team already maintains |
| Data quality | Duplicates, placeholder values, inconsistent formats and missing identifiers | Sources profiled early and fixed upstream before they are connected |
| Identity resolution | No shared identifier, shared household or business emails, and several brands or regions | A reliable common key such as a customer number or verified email |
| Data model fit | Heavy use of custom objects and one-off mappings | Standard data model objects used wherever they fit, with documented conventions |
| Insight and segment definitions | Metrics each team defines differently, and dozens of requested segments | A few definitions signed off in writing before anyone builds them |
| Activation targets | Many destinations at once: CRM records, marketing channels, flows and agents | One activation target for the first release |
| Freshness requirements | Near-real-time or streaming needs for every source | Batch refreshes where the business decision does not need anything faster |
| Consent and privacy | Consent spread across systems with no rule for which source wins | Consent objects mapped in the first release and tested with real opt-outs |
| Organization structure | Several brands or regions that need separate data spaces and permissions | One business unit with a single owner for the first phase |
Integration work often sits inside the source driver. If a system has no connector, the effort looks like any other Salesforce integration, and our integration cost guide covers those drivers in more depth.
How does consumption-based pricing affect cost?
Data 360 is not a simple per-seat purchase. Salesforce offers consumption-based credits alongside profile-based options, and different activities draw on consumption at different rates.
Structurally, this means the running cost follows what the platform does, not how many people log in. Batch ingestion and zero-copy access are now free. Streaming data, identity resolution, segment builds and refreshes, activation and queries consume credits, unless you choose profile-based pricing, which covers profile-building work with a flat per-profile fee. A source streamed in full when a subset would do, or one that feeds every identity resolution run, costs more every cycle. So does a segment refreshed more often than anyone uses it.
Before signing, ask your account team four things:
- Which pricing model suits your expected volumes, and whether any entitlement is already bundled with licenses you own.
- How storage is counted, and how each activity in your first use case is metered.
- What happens when usage exceeds your commitment.
- Which admin tools show consumption by feature, so you can track it after go-live.
Ask for a usage estimate tied to your specific first use case, not to the platform as a whole. Then review actual usage after the first month and adjust refresh schedules and ingestion scope.
What should be in place before you start?
You need a named use case, reachable sources with owners, and a CRM clean enough to trust. Without those, the project spends its first phase discovering problems it could have fixed more cheaply beforehand.
- One use case with a measurable outcome and a business owner.
- A list of source systems, each with an owner and a confirmed way to access the data.
- Agreed identifiers for matching, such as email, customer number or account ID.
- A decision about which system is authoritative for each important field.
- Consent and privacy requirements reviewed, especially for consumer data and regulated industries.
- Core CRM data in reasonable shape, with known duplicate problems addressed.
- A platform owner and a data steward named for after go-live.
- A consumption estimate reviewed against your contract.
If you plan to ground Agentforce agents in this data, check agent readiness at the same time. Our Agentforce readiness checklist covers the data, security and governance questions.
What are the most common mistakes?
Most expensive mistakes come from starting too wide or treating go-live as the finish line. Each one below adds time during the build or cost afterwards.
- Ingesting everything before choosing outcomes. It multiplies mapping work, raises consumption and leaves a large dataset with no agreed use.
- Merging on weak identifiers. Shared emails, business phone numbers and test values can collapse different people into one profile.
- Treating unification as cleansing. Identity resolution links records; it does not fix a wrong phone number or a missing industry.
- Ignoring consent at ingestion. If opt-outs from one system are not mapped, segments can include people who asked not to be contacted.
- Building insights before definitions are agreed. Each team then keeps its own version, and nobody trusts the shared one.
- Skipping review with business users. People who know customers spot bad matches quickly; a test script does not.
- No owner after go-live. Source systems change fields and retire feeds, and profiles degrade quietly without someone watching.
How should you scope a first phase?
Scope the first phase backward from one activation target. Include only the sources, fields, rules and definitions that target needs, and put everything else on a roadmap.
A practical first phase often looks like this:
- Pick one output, such as a unified profile on the contact record, one marketing segment or an agent's grounding source.
- Connect the two or three sources that output depends on, and profile them before mapping.
- Start with conservative match rules and review sample profiles with the people who use them.
- Add one calculated insight only if the output needs it, with a signed-off definition.
- Set refresh schedules to what the decision needs, and estimate the consumption they create.
- Write a runbook for ownership, monitoring and consent before launch.
Also write down what is out of scope, with the reason. That list protects the timeline and becomes the backlog for phase two.
A business lender we worked with shows the pattern. It received 24,000 leads a month and held customer data across a risk engine, a servicing platform and Salesforce. The engagement produced a Data Cloud architecture and phased roadmap to unify 10 terabytes of data from those systems. It also delivered a lead-prioritization framework the team could use immediately, rather than waiting for every source to be connected.
That sequence works for most companies. Start with the decision, design an architecture that can grow, deliver value from existing data where you can, and add sources in phases.
What happens after go-live?
Data 360 becomes a production system that needs ownership, like any other. The ongoing cost is consumption plus the time to monitor and adjust it.
Plan for a platform owner who watches data streams, errors and consumption, and a data steward who reviews match rules and profile quality. Each segment or insight also needs a business owner. Review consumption by feature on a schedule, and retire segments and refreshes nobody uses. Each new source or activation target is then a small, scoped project of its own, not a reopening of the whole platform.
