Data lineage in Data 360

An agent tells a customer their available credit is $4,200. The customer disputes it. Now someone on your team has to answer a question that sounds simple and isn’t: where did that number come from? Not “what did the model say” — the model faithfully read a field it was handed — but which source system, which ingestion run, which transform, which merge decision produced the available_credit value the agent grounded on. If you can’t reconstruct that chain in minutes, you don’t have a data platform you can put an agent on top of. You have a confident guess with a UI.

This is the lineage problem, and it’s moved from a governance nicety to a hard requirement precisely because agents now act on unified data instead of just displaying it. A dashboard that’s wrong wastes an analyst’s afternoon. An agent that’s wrong emails a customer, adjusts an entitlement, or triggers a downstream flow — unattended, at event speed. The blast radius of a bad number went up, so the ability to trace any number back to its origin has to come up to meet it. This post is about how lineage actually works in Data 360, what it does and doesn’t give you natively, and what changed when Salesforce finished absorbing Informatica.

What lineage means here, precisely

“Data lineage” gets used loosely, so pin it down. Lineage is the recorded, queryable answer to two questions about any field or record in your unified data:

Provenance (backward): what did this value come from — which source system, which data stream, which Data Lake Object, which transform, which merge — all the way back to origin?
Impact (forward): if this source or this transform changes, what breaks downstream — which Data Model Objects, which insights, which segments, which activations, which agents?

In Data 360 the pipeline you’re tracing is always the same shape: a data stream ingests from a source into a Data Lake Object (DLO); Data Transforms reshape and join DLOs; mapping harmonises them into Data Model Objects (DMOs); identity resolution merges records into unified profiles; and insights, segments, and retrievers sit on top, feeding an agent’s grounding. Lineage is the thread that runs through every one of those hops. When the thread is intact, “where did $4,200 come from” is a lookup. When it’s broken at any hop, it’s an archaeology project.

Lineage isn’t documentation you write after the fact. It’s metadata the platform captures as data moves — or it’s a story you reconstruct from memory when someone’s already angry.

What Data 360 tracks natively — and where it stops

Before you reach for anything new, know what the platform already records, because a surprising amount of lineage is built into the object model itself.

Every DLO and DMO carries a set of lineage fields that travel with the record: DataSource, DataSourceObject, and InternalOrganization. These aren’t cosmetic — they identify which source and which source object a given row originated from, and they’re queryable through the Query API like any other field. When a streaming Data Transform writes to a target object, it copies the lineage field values from source to target, so a harmonised DMO row still knows which raw DLO it came from even after several transformation hops. That’s genuine record-level provenance, and most teams don’t realise they already have it.

Data classification rides the same rails. If you tag a field as PII or apply a sensitivity classification at the DLO, tag propagation follows the lineage path — DLO → DLO → DMO — so classifications automatically flow from raw ingested data through transforms and into the harmonised layer and any derived objects. This is the mechanism that makes right-to-be-forgotten and governed agent access enforceable at scale: you classify once at the source and the label travels, instead of hand-tagging every derived object and praying you didn’t miss one.

Where native tracking stops is the world outside Data 360. The lineage fields tell you a row came from DataSource: Snowflake_Prod, but they don’t tell you what happened inside Snowflake before it arrived — which upstream job populated that table, which ETL step transformed it, which system of record fed that. For a zero-copy federated source, the data never physically lands in Data 360 at all, so your provenance genuinely begins at a boundary you can’t see past with native tooling alone. In an enterprise where the customer record is assembled from six systems, “lineage that starts at the Data 360 ingestion point” answers the easy half of the question and shrugs at the hard half.

What the Informatica acquisition actually adds

Salesforce completed its acquisition of Informatica on November 18, 2025, and lineage is one of the clearest reasons it did. Informatica’s stack — Data Catalog, enterprise Data Lineage, Master Data Management (MDM), data quality, and unified metadata management — is built to do exactly the thing native Data 360 tracking can’t: map metadata and lineage across every system, not just Salesforce.

The practically important pieces, verified against what Salesforce has published so far:

An enterprise metadata and lineage engine. Informatica provides an enterprise-wide view of metadata that pulls in context and lineage across your whole estate — the warehouses, the on-prem databases, the SaaS apps upstream of Salesforce — not only the segment that lives inside Data 360. This is the “backward past the ingestion boundary” capability the native lineage fields lack.
The Data 360 Connector and Scanner. Announced as generally available in May 2026, this delivers real-time, bidirectional data flow between enterprise systems and Data 360 across hybrid, multicloud, and on-premises environments — with end-to-end lineage carried across the connection rather than lost at the handoff.
MDM as the trusted-identity layer. Informatica MDM sits alongside Data 360’s native identity resolution rather than replacing it overnight. Native match-and-merge unifies profiles inside Data 360; enterprise MDM governs the golden record across systems. Which one owns identity for a given domain is now an architecture decision, not a default.

Be precise about timing when you plan around this. The acquisition closed in late 2025 and integration is rolling out in stages through 2026 — the Connector and Scanner are the first GA deliverables, with catalog and MDM integration arriving on their own schedules. Treat “Informatica-powered lineage in Data 360” as a capability that is arriving, verify the specific piece you need against current release notes before you design on it, and don’t assume the full enterprise catalog is wired into your org the day you read this.

The bird’s-eye view, and why it’s more than a diagram

Recent Data 360 releases added a visual, end-to-end view of data movement and dependencies from source to activation — the “bird’s-eye view” Salesforce highlights in its release material. It’s easy to dismiss as a prettier diagram. It isn’t, for one reason: it’s the difference between impact analysis you can do and impact analysis you skip because it’s too painful.

Here’s the scenario it exists for. An upstream team is about to rename a column or retire a source table. In an ungoverned platform, the honest answer to “what will this break” is “we’ll find out in production.” With a dependency view, you trace forward from that source object and see the actual chain: this DLO, these two transforms, this DMO, these three calculated insights, the segment that feeds your ad audiences, and the retriever grounding your service agent. The change goes from a blind risk to a scoped one. That’s the whole value of lineage as an operational tool rather than an audit artifact — it turns “we think it’s fine” into a list you can actually check.

Using lineage to prove an agent’s grounding

Now connect it back to the agent, because this is where lineage stops being a data-team concern and becomes an AI-trust concern.

An agent’s answer is only as trustworthy as the chain beneath the field it read. When you can trace that chain, you can do three things you otherwise can’t:

Answer the audit question. When the $4,200 credit figure is disputed, you walk it backward: the agent read available_credit on the unified profile; that DMO field maps from the Accounts_DLO; that DLO is fed by the Core_Banking data stream; the last refresh ran at 03:14; the transform that derives available-from-limit-minus-holds is version 7. Now you have a defensible answer instead of a shrug, and — just as often — you find the actual bug, which is usually a stale stream or a transform that changed, not the model.
Scope what an agent is even allowed to ground on. Tag propagation means sensitivity classifications ride the lineage path into every derived object. So when you configure what an agent can see, you’re enforcing labels that were set once at the source and travelled — not labels someone remembered to reapply on the DMO. Lineage is what makes that guarantee real rather than aspirational.
Separate a retrieval problem from a data problem. When an agent is confidently wrong, the instinct is to blame the model or the prompt. Lineage lets you check the cheaper hypothesis first: was the field itself wrong before the model ever saw it? Often the fix isn’t in the agent at all — it’s a broken transform three hops upstream, and no amount of prompt-tuning would have caught it. This is the same discipline as getting data quality right for AI, with lineage as the tool that tells you where to look.

There’s a natural pairing worth stating outright. Lineage answers where a value came from; the semantic layer answers what a value means — so the agent doesn’t invent your definition of “active customer” or “available credit.” A production agent grounded on structured data needs both: lineage so you can trace the number, and a semantic layer so the number means the same thing to the agent that it means in your board deck.

Where teams get it wrong

Three failure patterns show up repeatedly, and all three are cheaper to avoid than to unwind.

Treating lineage as an afterthought you’ll add later. Lineage you didn’t capture as data moved is lineage you’re reconstructing from tribal memory. Design your streams, DLOs, and transforms so provenance is intact at every hop from day one — preserve the lineage fields, don’t flatten sources into an anonymous blob, and keep transforms named and versioned. Retrofitting provenance onto a pipeline that discarded it is the expensive path.
Assuming native tracking covers the enterprise. The lineage fields are excellent for the segment of the journey inside Data 360 and silent about everything upstream of ingestion. If your regulator, your auditor, or your own incident review needs origin-to-activation lineage across systems, that’s the Informatica catalog’s job — scope it in deliberately rather than discovering the gap during an audit.
Confusing lineage with access control. They’re complementary, not the same. Lineage tells you where data came from; access control decides who and which agent can see it. You need both, and the reason tag propagation matters is that it’s the bridge — classifications set at the source ride the lineage path into the access decisions downstream.

The takeaway

The moment you let an agent act on unified data, you inherit an obligation the dashboard era let you dodge: to prove, for any value the agent used, exactly where it came from. Data 360 gives you more of that natively than most teams realise — lineage fields that travel with records, tag propagation that carries classifications along the DLO → DLO → DMO path, and a dependency view that turns impact analysis from guesswork into a checklist. The Informatica acquisition extends the trace past the ingestion boundary into the rest of your estate, with the Connector and Scanner as the first GA piece and the catalog and MDM arriving on their own timeline. Build so provenance is intact at every hop, pair lineage with the semantic layer so an agent grounds on the right number and the right meaning, and remember what the whole thing is for: when someone finally asks where the number came from, you want a lookup, not an excavation.

Understanding the basics

What is data lineage in Salesforce Data 360?

Data lineage in Data 360 is the recorded trail of where a piece of data came from and where it flows to — from the source data stream, through the Data Lake Object, transforms, and mapping into a Data Model Object, and onward into insights, segments, activations, and agent grounding. Natively, DLOs and DMOs carry lineage fields (Data Source, Data Source Object, Internal Organization) that travel with records and are copied from source to target by transforms, and data-classification tags propagate along the lineage path (DLO → DLO → DMO). The Informatica acquisition adds enterprise metadata and lineage that extends the trace across systems beyond Data 360 itself.

How does the Informatica acquisition change Data 360 lineage?

Salesforce completed its acquisition of Informatica in November 2025, bringing an enterprise Data Catalog, cross-system Data Lineage, MDM, and unified metadata management. Where native Data 360 lineage begins at the ingestion boundary, Informatica’s engine maps lineage across your whole estate — warehouses, on-prem databases, and upstream SaaS apps. The Data 360 Connector and Scanner, generally available in May 2026, carry end-to-end lineage across real-time, bidirectional connections spanning hybrid, multicloud, and on-premises environments. Integration is rolling out in stages through 2026, so verify the specific capability you need against current release notes.

Why does lineage matter for AI agents?

Because agents now act on unified data rather than just displaying it, any value an agent grounds on can end up in a customer-facing answer or an automated action — so you must be able to trace that value to its source. Lineage lets you answer audit questions (“where did this number come from”), enforce sensitivity classifications that ride the lineage path into agent-access decisions, and distinguish a retrieval or model problem from an upstream data problem. It pairs with the semantic layer: lineage proves where a value came from, and the semantic layer defines what it means.

Trying to make an agent’s grounding auditable — or work out where native Data 360 lineage stops and enterprise cataloguing has to start? Talk to us. Getting provenance intact before an agent ever reads the field is exactly the work we do.

Data lineage in Data 360: tracing an agent's answer back to its source