A question I get on almost every architecture review these days: “Should we get Data Cloud?” Sometimes the honest answer is yes. More often, the honest answer is: Data Cloud will happily store your problem at scale — it won’t fix it.

This isn’t an anti-Data Cloud post. It’s a genuinely capable platform. But it’s also the current default answer to every data question in the Salesforce ecosystem, and defaults are how architecture debt happens. So here’s the framework I actually use.

What Data Cloud actually is (in one paragraph)

Strip away the marketing and Data Cloud is a hyperscale lakehouse sitting next to your core org: you stream or batch data in (data streams → Data Lake Objects), map it to a canonical model (Data Model Objects), optionally run identity resolution to unify profiles, build calculated insights and segments on top, and activate the results back into Salesforce, Marketing Cloud, or external systems. It handles volumes the core platform was never designed for, and it does near-real-time processing that would melt a trigger-based design.

That’s a real capability set. The question is whether your problem needs those capabilities.

When Data Cloud genuinely solves the problem

These are the cases where I recommend it without hesitation:

  • You have multiple sources of truth and need one profile. Customer data in the CRM, transactions in an ERP, behavior in a web platform, consent in a third system. Identity resolution — matching and reconciling records across sources into unified individuals — is Data Cloud’s signature feature, and building it yourself is a project you will regret.
  • The volume breaks the core platform. Hundreds of millions of events, telemetry, transaction history. Core objects hit practical limits long before that; Big Objects buy you storage but take away querying, reporting, and triggers. Data Cloud is built for exactly this.
  • You need segmentation and activation, not just storage. If the end goal is “build an audience from behavior + CRM attributes and push it to engagement channels,” that’s the native motion. Rolling your own means exporting, transforming, and re-importing forever.
  • You’re grounding AI in real data. Agentforce agents and generative features need context at a scale and freshness the core org can’t serve. Data Cloud is the retrieval layer Salesforce is building its AI story on — and it shows.

Notice what these have in common: the problem is federation, scale, or activation — not the quality of the data itself.

When Data Cloud just moves the problem

Now the uncomfortable list — the patterns where Data Cloud is the wrong spend:

  • “Our data is a mess, Data Cloud will unify it.” No — it will ingest your mess, faithfully, at scale. Duplicates, inconsistent values, stale records: identity resolution can match records, but it can’t make a half-empty Contact trustworthy. Garbage in, harmonized garbage out. I’ve written before about why data quality is the quiet blocker for AI ambitions — Data Cloud raises the stakes, it doesn’t lower them.
  • “We need better reporting.” If the pain is dashboards and cross-object reporting in one org, the fix is your data model, CRM Analytics, or both. Data Cloud is a spectacularly expensive reporting tool.
  • “We need to integrate two systems.” Data Cloud is not middleware. If records need to flow between systems transactionally, you want an integration platform or well-designed APIs. Data Cloud ingests on a schedule or stream — it’s an analytics and activation plane, not an operational one.
  • “We need to archive old records.” Sometimes true, but do the math first. Big Objects, an external warehouse, or a purpose-built archiving solution may cost a fraction of the credits for a write-once-read-never workload.

The five questions I ask before recommending it

Before Data Cloud goes on any roadmap I’m reviewing, I want clear answers to:

  1. How many sources of truth are there, really? One Salesforce org with messy data is a cleanup project, not a Data Cloud project.
  2. Do you need identity resolution? If yes, the shortlist of alternatives gets very short, very fast.
  3. Where does the result get activated? Data that goes in but never drives a segment, an insight, or an agent is shelfware with a credit meter.
  4. Who owns it after go-live? Data Cloud needs ongoing stewardship — mappings drift, sources change, identity rules need tuning. “Nobody, after the implementation partner leaves” is a red flag.
  5. Have you modeled the credit consumption? Consumption-based pricing is predictable only if someone actually models your data volumes and processing patterns first. Surprises here are expensive.

If a project can’t answer 1–3 crisply, I push back — and usually the real work turns out to be upstream: fixing the data, the model, or the process.

The prerequisite nobody budgets for

Here’s the pattern I see most often: a team buys Data Cloud as the foundation for their AI roadmap, starts ingestion, and discovers — in the unified profile, where everything is suddenly visible side by side — that the underlying data contradicts itself everywhere. The project becomes a data cleanup effort wearing a Data Cloud budget.

The unglamorous truth: Data Cloud projects succeed in proportion to the data quality work done before ingestion starts. Measure completeness, duplication, consistency, and freshness in your sources first. Fix what matters. Then unify. Tools like Data Quality Sense exist precisely to make that measurement cheap instead of a six-week manual audit — but whatever you use, don’t skip the step.

The takeaway

Data Cloud is a strong answer to a specific question: “How do we unify, understand, and activate data at a scale the core platform can’t handle?” If that’s your question, it’s excellent. If your question is actually “how do we fix our data,” “how do we report better,” or “how do we connect two systems” — Data Cloud won’t solve your problem. It will just move it somewhere with a bigger bill.

Ask the five questions. Do the data quality work first. Then, if Data Cloud is the answer, it will actually be the answer.