Agentic setup in Data 360: what an agent can scaffold in your pipeline, and the calls it can't make

The pitch is appealing, and for once the demo is close to the reality. Salesforce is bringing the agentic treatment to Data 360 itself: alongside Setup with Agentforce, the natural-language admin assistant that reached general availability in the Summer ‘26 wave, the platform is adding agent-assisted setup and data management inside Data 360, where you describe what you want in plain language and the system proposes the pipeline: connect this source, shape it with a transform, map it to the model, build the segment. The stated goal is to “orchestrate your data pipeline with smart suggestions” and let people of varying expertise get further without menu-diving through a product that has never been accused of being simple.

If you’ve ever stood up a Data 360 pipeline from scratch, you know how much of it is mechanical: creating a data stream, drafting a transform, clicking through a field-by-field mapping, wiring a segment to an activation target. An agent that drafts that scaffolding is a real time-saver, and it’s the correct direction for a platform this dense. But there’s a trap hiding in the word “orchestrate,” and it’s the same trap that shows up every time a natural-language layer gets bolted onto a system where the hard part was never the clicking. The agent optimizes for a configuration that works. Your job is a configuration that’s right. Those are not the same target, and the gap between them is measured in privacy incidents and credit bills. Here’s the honest split: what to let the agent scaffold, and the four decisions you keep.

The pipeline the agent is scaffolding

To see where the agent helps and where it can’t, you have to hold the actual shape of a Data 360 pipeline in your head, because the agent is proposing steps along it. Under the Data 360 rebrand the internal object names are unchanged, and they’re what the agent is manipulating:

A data stream ingests a source into a Data Lake Object (DLO), the raw data, stored in its original shape.
A data transform reshapes it. This comes in two flavors that are not interchangeable, and the difference matters for both capability and cost (more below).
A mapping connects DLO fields to a Data Model Object (DMO): the standardized model that identity resolution, segmentation, and grounding read. Mapping is a separate step from transforming, and the DLO-versus-DMO distinction is the one that decides everything downstream.
An identity resolution ruleset runs over the DMOs, never the raw DLOs, to unify records into a single profile.
Segments are built on the unified profiles, and activations publish them to a target.
Retrievers and grounding expose the result to an Agentforce agent.

An agent can meaningfully accelerate the boilerplate at almost every step: proposing a streaming-transform SQL skeleton, suggesting field mappings for well-known standard objects, drafting a segment from a natural-language description of the audience. Natural-language segment building in particular is a real, shipping capability, not a mockup. If that were all this feature did, turn the tedious parts into a conversation, it would be an unambiguous win.

The problem is that four of those steps contain a decision the agent can’t make for you, and each one fails silently. Nothing throws an error. You get a pipeline that runs, returns data, and is wrong in a way you won’t notice until it’s activated to a customer.

Decision one: the match key, which the agent can only guess

Identity resolution is where Data 360 earns its keep and where it does the most damage when it’s wrong. A ruleset is a set of match rules and reconciliation rules, and the single highest-use choice in the entire pipeline is what you match on.

An agent can read your field names and propose a plausible key. It sees email, phone, customer_id and suggests matching on them. What it cannot know is your business’s actual identity semantics: whether that customer_id is unique per person or reused across a household, whether your email column is polluted with shared info@ mailboxes, whether the loyalty number is the real anchor. Those are facts about your data and your business, not your schema, and they’re invisible to a model reading column headers. The agent will confidently propose a key that looks right and produces a working ruleset. Whether it’s the correct key is a question only someone who knows the data can answer.

Decision two: how broad the match rules go, the over-merge trap

This one deserves its own section because it’s where a helpful agent does the most harm, and the mechanism is subtle. Within a single match rule, the criteria are ANDed together. But a record unifies if it satisfies any one rule, the rules are ORed. That means every match rule you add broadens matching. Adding rules feels like adding precision; it adds reach.

Now imagine an agent trying to be helpful. You tell it the consolidation rate looks low, and it does the obvious thing: it adds a couple more match rules to catch more matches. It has just made your matching looser, and loose matching over-merges. Over-merge fuses two real people into one hybrid profile, the classic case is spouses sharing a household email, collapsed into a single unusable record. And here’s why that’s not a data-quality footnote but a genuine incident: once two people are merged, every downstream system acts on the hybrid. A segment activates one person’s loyalty balance to the other person’s inbox. A grounded service agent reads one customer their history and includes another customer’s orders. That’s not a bug you clean up next sprint. It’s a privacy incident that already shipped.

The discipline that prevents it is exactly the discipline an agent doesn’t have: every rule needs an anchor. A fuzzy criterion widens a match; an exact, high-trust criterion (a normalized phone, a loyalty number, a deterministic party ID) is what justifies unifying two records at all. Fuzzy-on-fuzzy rules are how strangers get merged. The right build is deterministic high-confidence IDs first, then contact-point rules layered in carefully and one at a time, watching the consolidation rate move. That’s the opposite of “the agent added a few rules to raise the match rate,” and it’s precisely the judgment covered in identity resolution in Data 360 that no amount of natural-language scaffolding replaces.

Decision three: streaming versus batch, where the wrong default bloats the bill

The two kinds of data transform look similar in a conversation and behave nothing alike. A streaming transform runs continuously on near-real-time data, but it’s built from a single SQL statement against a single object, no joins. A batch transform runs on a schedule, has a visual editor, and can join multiple DLOs, compute calculated fields, and output to several targets. The batch-versus-streaming choice decides what you can even build, and it also decides what you pay.

Here’s the failure mode. Ask an agent for “a transform that keeps this data fresh” and fresh nudges it toward streaming, which is the more expensive processing path, and one you should reserve for cases that need real-time. An agent optimizing for the literal request will happily default you into continuous processing you didn’t need, or run full refreshes where a delta would do, or transform after ingestion instead of filtering junk rows out upstream. None of that errors. It shows up on the consumption bill, weeks later, as a number nobody can explain, because Data 360 meters processing, and a chatty, always-on transform is a standing charge. “Make it fresh” is a business decision about latency and cost. The agent hears it as a SQL request.

Decision four: what a DMO mapping commits to

Mapping DLO fields to a DMO looks like the most mechanical step in the pipeline, which is exactly why it’s dangerous to hand off blind. The mapping is what makes data usable for identity resolution, segmentation, and grounding, and a wrong mapping doesn’t fail loudly, it quietly corrupts everything downstream. Map a field to the wrong standard attribute and identity resolution reads the wrong identifier; segments filter on data that isn’t what they think it is; the grounded agent retrieves a field that means something other than its label suggests.

An agent is good at the well-trodden cases (person data to the Individual DMO, an email to Contact Point Email) and you should let it draft those. But the moment your source has ambiguity the model can’t resolve from names alone (which of three date fields is the event date, whether this identifier belongs on the person or the account, how a custom object should type), the mapping becomes a modeling decision. Accept the agent’s draft as a draft, and review every mapping that touches an identity field or a segmentation attribute as if you’d made it yourself, because downstream, you did.

What the agent is good for

None of this is an argument against agentic setup. It’s an argument for using it where it pays and reviewing it where it bites. The agent earns its place on the mechanical majority: standing up a stream, drafting the obvious mappings, scaffolding a transform’s SQL, translating “customers in California who bought in the last 90 days” into a segment you then inspect. It’s a genuine accessibility win for teams without a trained Data Cloud specialist on call, and it shortens the distance from connection to a working draft. Treat it as a fast, tireless junior who produces a plausible first pass, that framing gets you the speed without the false confidence.

The mistake is treating an agentic workflow as a self-healing data layer with no approval boundaries, letting it modify pipelines at runtime and assuming it optimizes for correctness. It optimizes for a working config. The governance question that matters is the same one you’d ask of any agent with write access: what may it do autonomously, and what has to stop for a human? For a pipeline that feeds identity resolution and grounds customer-facing agents, the answer for the four decisions above is: a human signs. The honest version of “agentic setup” isn’t the agent building your pipeline while you watch. It’s the agent doing the typing while you make the four decisions that were always the actual job.

This is the same lesson Setup with Agentforce is teaching admins one release earlier: the natural-language assistant is a real accelerator for surfacing and drafting configuration, and it is not a replacement for the judgment calls that carry security and data consequences. Data 360 raises the stakes because its wrong answers are quieter and its blast radius is your unified customer record, the foundation every grounded agent stands on. Scaffold with the agent. Decide for yourself.

Understanding the basics

What is agentic setup in Data 360?

It’s Salesforce bringing natural-language, agent-assisted configuration to Data 360. Part of the same Summer ‘26 agentic wave that made Setup with Agentforce generally available for org admins. Instead of clicking through Setup to build each pipeline step by hand, you describe what you want and the system proposes the pieces: a data stream to ingest a source, a transform to reshape it, a mapping to the data model, a segment. It’s designed to lower the barrier for users of varying expertise and to collapse the mechanical work of standing a pipeline up. It does not remove the modeling and governance decisions that determine whether the resulting pipeline is correct.

Where does an agent help versus where should a human decide?

The agent helps with the mechanical majority: creating streams, drafting transform SQL, proposing field mappings for well-known standard objects, and translating a plain-language audience description into a segment you then inspect. Humans keep four decisions because each fails silently: the match key identity resolution uses, how broad the match rules go (adding rules broadens matching and risks over-merging distinct people), streaming versus batch transforms (the wrong default inflates the consumption bill), and DMO mappings that touch identity or segmentation fields. Accept the agent’s output as a reviewable draft, not a finished configuration.

Why is over-merging in identity resolution so dangerous?

Because a record unifies if it satisfies any one match rule (rules are ORed), every rule you add broadens matching, so an agent “helpfully” adding rules to raise the match rate makes matching looser, and loose matching fuses distinct people into one hybrid profile. Once merged, every downstream system acts on the hybrid: a segment can activate one person’s data to another person’s inbox, and a grounded agent can read one customer another customer’s history. That’s a privacy incident, not a data-quality cleanup. The fix is to anchor every rule on an exact, high-trust identifier and layer fuzzy contact-point rules in gradually while watching the consolidation rate. Judgment an agent reading column names can’t supply.

Does agentic setup change the Data 360 credit cost model?

It doesn’t change the meter, but it changes who is choosing the settings that drive the meter, and that’s the risk. Data 360 bills by consumption, and streaming transforms, full refreshes, and post-ingestion filtering all cost more than their batch, delta, and upstream-filter equivalents. An agent optimizing for a literal request (“keep it fresh”) can default you into the expensive path without flagging it, so the bill moves before anyone connects it to a setup choice. Review the transform type and refresh strategy the agent proposes against your actual latency needs, and forecast the consumption the way you would for any Data 360 pricing decision.

Standing up a Data 360 pipeline, or cleaning up one an agent scaffolded a little too enthusiastically, and want the match rules, transforms, and mappings to be right before they ground an agent? Talk to us. Getting the data foundation right is exactly the work we do.