Does Agentforce Require Data Cloud? A Decision Framework

It's one of the most common questions we get asked, and it's usually asked with a sinking feeling: "We want to build an agent. Do we have to buy Data Cloud first?"

The honest answer is that it depends on what your agent needs to know — and for a meaningful share of the use cases that mid-market teams actually want to build, the answer is no. The two products are related, and Salesforce positions them together for good reasons, but they are not inseparable, and treating them as a mandatory bundle can turn a focused six-week project into something considerably larger and slower.

This is the framework we use to work it out. It takes about twenty minutes with the right people in the room, and it will usually give you a clear answer.

The question underneath the question

An agent needs to ground its answers in something. The real question is never "do I need Data Cloud" in the abstract — it's "where does the information my agent needs actually live, and is it already usable where it sits?"

Data Cloud earns its place when the answer involves unifying data from multiple systems into one real-time profile. If your agent only needs things that already sit in your Salesforce org, cleanly, you may be adding a large piece of architecture to solve a problem you don't have.

So work through the following in order. Stop at the first one that clearly describes your situation.

Case 1: Everything the agent needs is already in Salesforce

Your agent answers questions about cases, opportunities, accounts, contacts, orders or knowledge articles — and all of that lives in your org today, reasonably clean and reasonably current.

You probably don't need Data Cloud. An agent can be grounded directly in your Salesforce records and your knowledge base. This covers a lot of genuinely valuable use cases: case deflection on documented topics, internal assistants that help reps find account context, service agents answering from existing knowledge, and drafting help for support and sales staff.

What you do need instead is the unglamorous work: clean records, deduplicated accounts, knowledge articles that are current and written clearly, and a sensible sharing model. That work is the actual prerequisite, and skipping it is what causes agent projects to disappoint — not the absence of Data Cloud.

Case 2: The agent needs one or two things from one other system

Your agent mostly works from Salesforce, but it needs order status from your ERP, or subscription state from your billing platform, or shipping information from a logistics provider.

You probably still don't need Data Cloud. One or two well-scoped integrations will usually be cheaper, faster and easier to reason about than standing up a unification layer. Depending on the system and the freshness you need, that might be an API call at the moment the agent asks, or a straightforward sync into a Salesforce object.

The thing to be careful about here is freshness. If the answer must be accurate to the minute, a nightly sync is not an integration — it's a source of confidently wrong answers. Decide the tolerance before you pick the approach.

Case 3: The agent needs a unified view across many systems

Your customer exists in several places at once — a web analytics profile, an e-commerce record, a marketing platform, a support system, a billing system — and the agent's usefulness depends on seeing them as one person with one history.

This is what Data Cloud is for, and this is where it earns its cost. Identity resolution across sources, a real-time unified profile, and the ability to activate that profile is a genuinely hard problem to solve any other way. If you try to solve it with point-to-point integrations you will end up building something that resembles Data Cloud, only worse and with nobody maintaining it.

Be honest about whether you are actually in this case, though. Wanting a single view of the customer is nearly universal. Needing one, in real time, for the specific agent you are about to build, is much less common.

Case 4: The agent needs to act on behaviour as it happens

You want the agent to respond to what someone is doing right now — browsing a particular product, abandoning a process, hitting a usage threshold — rather than to what is recorded about them.

This also points to Data Cloud , because real-time ingestion and activation is precisely the capability being bought. Batch data cannot do this, and a series of integrations will not do it well.

A test that cuts through most of the debate

Write down the ten questions you most want the agent to answer. For each one, write where the answer lives today.

If eight or nine of them point at Salesforce, build the agent on Salesforce and integrate the exceptions. If they scatter across four or five systems, and the value depends on connecting them, you have your answer the other way.

This sounds almost too simple, but it is remarkable how often a team that was certain they needed a unification project discovers that nine of their ten questions were answerable from data they already had — and how often a team that thought they could get away with a quick build discovers the opposite.

A sequencing point worth more than the licensing decision

Even when Data Cloud is genuinely the right destination, it does not have to be the first step.

There is often a well-scoped agent you can build now on the data already in your org — one that delivers something measurable, teaches your team how these systems behave in production, and builds internal confidence — while the larger data work proceeds on its own timeline. Sequencing that way tends to produce better outcomes than a long build with nothing visible until the end, and it means the data programme has a concrete consumer pulling it forward rather than being a project everyone loses patience with.

The failure mode we see most often isn't picking wrong. It's picking a large architecture first, spending two quarters on it, and never getting to the agent that was supposed to justify it.

What to do with your answer

If you landed in Case 1 or 2, your next move is a data-quality and knowledge review, not a licensing conversation. If you landed in Case 3 or 4, the licensing conversation is real — but you should still ask what can ship in the meantime.

And if you genuinely can't tell which case you're in, that is itself useful information: it usually means the use case isn't specific enough yet, and another hour defining it will save considerably more than an hour of build.

If you'd like help working through it, our free Org Health Check looks directly at your data quality, integration state and AI readiness inside your own org, and gives you a written summary of what to fix first. No cost, no obligation — and if the honest answer is that you're not ready for an agent yet, we'll tell you that too.