How to integrate external AWS data lakes with Salesforce Data Cloud

A team federates a wide behavioural table so the contact centre can "see the lake." Nobody measures the query. The design review is told the read will be fast because nothing was copied. At nine in the morning the warehouse is fine. In the middle of a campaign the same query waits, and the agent waits with it. The recovery proposal is to copy the whole lake into Data 360. Now there are two retention regimes, two access lists, and a correction in the lake that will not repair the copy until someone builds a load nobody scoped.

#Two patterns, and the current product name

The product people still call Data Cloud is Data 360. Salesforce rebranded it on 14 October 2025. The behaviour is unchanged. For an external lake the practical choice is still the one the help page allows: ingest data, or connect it with zero copy data federation. The page says it directly: "Connect data using zero copy data federation." Ingest brings rows into Data 360, including by streaming or by batch. Federation queries the external store and leaves that store in charge of the bytes.

Zero copy is federation. It is not a latency promise. Avoiding a duplicate does not tell you how long a query will take, whether the lake can carry the pattern you are about to point at it, or what the agent sees when the lake is busy. Those are measurements. They do not exist until you run the query you actually intend, against the volume you actually have. A number borrowed from another estate is fiction. Do not put one in the design.

Do not start from a connector catalogue. Names for AWS links move, and a wrong identifier in a design document becomes a procurement argument. This page will not invent one. Describe the pattern. If a named connector is required, confirm it in the current documentation and in the org before you write it into a plan.

#What ingest actually duplicates

Ingest is the right pattern when Data 360 must hold the rows: a subject you will unify, a history you will segment without a live call to the lake, or a narrow feed a person is waiting on. You accept a copy. The copy needs an owner. Retention on the lake does not automatically retention the copy. A correction in the lake does not repair Data 360 until a load brings the correction across. Access on the lake does not answer who can see the copy inside Salesforce. Deletion in the lake does not delete the copy because you hoped it would.

Write that down as operating work, not as a footnote. Who reruns the load. Which key joins the lake row to a person or an account. How a deletion in the source is reflected, and how late. If those notes are blank, ingest is a dump, and the dump will be defended later as "the integration." A dump has no steward. It accumulates columns because adding a column feels like progress and removing one requires an argument.

Streaming ingest and batch ingest are both documented. Stream the event someone is waiting on. Batch the lake history. A full-lake stream is a bill attached to a storage decision you have not finished making. The lake emitting files all day is the lake's cadence. It is not evidence that a person in the CRM is blocked.

The copy also does not inherit meaning. A column called status in the lake and a column called status in the CRM are not the same fact until someone writes the definition. Ingest will store both. Identity resolution will relate the rows you stored. It will not notice that the two statuses contradict, and it will not override either of them.

#What federation leaves in place

Zero copy federation keeps the lake as the system of store. That is the point of it. Governance of the bytes stays where the bytes stay: the lake's retention, the lake's encryption, the lake's grants. You do not get to skip modelling. Data 360 still needs objects, keys, and a clear statement of which columns a segment or a profile is allowed to use. A federated table with two hundred columns is not a model. It is a window. Windows get used. Someone will filter a segment on a column nobody agreed was fit for a person to see.

Ask three questions before you promise a use case on a federated object. Can the lake carry this query while it is also serving the jobs it already has? What staleness, or what wait, does the consuming use case actually tolerate, as opposed to what the workshop preferred? What happens to the person in front of an agent when the lake does not answer? "It will be fine" is not an availability design. A live read that fails during a conversation is a worse failure than an answer that is an hour old, for most service work. Copy the narrow slice the conversation needs if you cannot accept the lake's outages as your own. Leave the wide history where it is.

Do not invent a latency figure to win the design review. Measure the path you turn on, with the query you run, and write the number down then. Until that test exists, the honest statement is that you have not measured it. Federation can still be the right pattern. It is the right pattern when the lake should remain the store and the consumer can live with what you measured, not with what you hoped.

Tableau Next does not replace Tableau. Pointing a workbook at a federated table does not settle ingest versus federation, and it does not make an unmeasured query fast. The help page says you can expand Data 360 using Tableau or Tableau Next. Use whichever the asker already opens. A chart of a federated extract that timed out is a clear picture of a pattern you have not tested. Fix the pattern, or label the chart with the cadence you actually achieved.

#Identity still has to be told the truth

Whichever pattern you choose, the rows that represent a person or an account have to be usable as keys. Identity resolution generates unified profiles from source profile data stored in Data 360. Unified profiles are keys. They are not a golden record. The engine does not pick a winning value and does not override source values. If the lake and the CRM both hold an email, and you bring both in, you will have two emails. Federation does not crown a winner any more than a copy does. Pick an authority per attribute before the first mapping workshop, and reject columns that have no authority.

The lake can own behavioural history. The CRM can own the account and the person. Data 360 can own the unified profile that points at both. If two systems own the same email, the project becomes a reconciliation, which is the failure this integration was supposed to avoid. "The lake is more complete" is a slogan until you have said, for email specifically, who wins when the lake is empty, and who wins when the CRM was edited this morning. Last-write-wins will hand the attribute to whichever pipeline ran last, including a normalisation job that changed nothing a person would recognise.

Blank keys survive both patterns. A federated row with an empty customer number does not match, any more than a copied row does. Count blanks in the lake before you promise unification. The count is cheap there. It is embarrassing after a segment has already used the profiles. The audit that belongs before the first load is the same one you would run on a CRM extract: blank match keys, conflicting emails, missing consent, and rows that are not a person or an account. A test harness row in a lake unifies beautifully if you let it, and then it appears in an activation.

#Name an owner for the row

The artefact is a page, not a platform diagram. Each subject you intend to use: the store, the pattern, the key, the consumer, and the person who owns the row. A subject with no consumer does not need a Data 360 path. Leaving it out is a decision. "Bring it in case" is how the window grows from ten columns to the full table.

Read the last row twice. Both patterns fail in design reviews for the same reason: someone describes a mechanism and the room hears a guarantee. The mechanism is ingest or federation. The guarantee people smuggle in is speed, completeness, or cleanliness. None of those travel with the connector.

The same page should say what you will not connect. Years of impression logs, finance grain nobody in the CRM will filter on, columns a security review has not seen. Saying no is part of the integration. A design that cannot name an exclusion is a design that will accept the next table by default.

#The decisions that get expensive later

Changing your mind after a consumer exists is ordinary and costly. A segment built on a copy expects the copy to answer when the lake is down. Move that object to federation and the segment inherits the lake's availability. A segment built on federation that you later copy will surprise you with storage, a refresh you must operate, and a week in which the copy and the lake disagree. Decide per object, with the consumer in the room, and revisit the decision when the consumer changes. Do not revisit it because a new connector name appeared in a release note.

Harmonising the shape is the part people postpone because the connection already "works." Works means a query returned rows. It does not mean an order is a header, a line, or both, or that a contact is a person rather than a person in a role. Those definitions are expensive to reverse once a segment counts on them. Write them in business language before you map. The wider set of choices that belong before ingestion, including copy versus reference, is in getting Data 360 right the first time.

Where the external store is a warehouse you already run for history, rather than a lake you are meeting for the first time, the split of jobs is the same argument with a different neighbour. Keep the warehouse for history. Use Data 360 where CRM identity, segments, and agents need the same person. That comparison is Snowflake and Data 360, and it does not include a benchmark either.

#A boring outcome

The outcome you want is dull enough to operate. A named pattern per object. A named owner per attribute. A model small enough to explain to the person who will be on the phone. A measurement, written down, for any path a person waits on. No connector name in the document unless someone has opened the current setup and confirmed it. No latency figure you have not produced yourself.

Then connect the smallest object that has a consumer. Read twenty rows with the owner of the source. If the key is blank, stop and fix the lake, or exclude the row. If the query is slower than the conversation can bear, copy the narrow slice or abandon the live read. Do not respond to a slow query by copying everything you federated. That response is how a federation decision quietly becomes a second platform, with none of the governance written down.