How to map existing CRM data to Salesforce Data Cloud

Someone exports every custom field on Contact because the connector can, and the workshop ends before lunch. Six months later every segment author is scrolling past three fields called status that contradict each other, two phone columns, and a notes field nobody can define. Identity resolution has related the profiles, noise included. It has not told anyone which status a seller meant. A chart sums a booking once on the account and again on every contact the account fields were copied onto. The dump felt fast. The segment is now slower to explain than the CRM was.

#Purpose first, then fields

The pages people follow still say Data Cloud. The product is Data 360. Salesforce rebranded it on 14 October 2025, and the behaviour is unchanged. You may still see the old name in the application and in the documentation. "While the name is new, the functionality and content remains unchanged." The job is still to ingest streaming and batch data, harmonise it, and unify it. Identity resolution then builds unified profiles from the source profiles you stored. It can only use what you mapped. That makes the mapping the design, not a prelude you rush so that ingestion can look finished.

Start from the questions you will ask in the first two segments, and from anything an agent must answer without guessing. Write the filters. Account id. Email. Consent. Country, if it is maintained. Opportunity stage, if sellers keep it current. Those columns are the map. A field with no question stays in the CRM. You can add it the week a question appears. You cannot easily unteach a segment that depends on a junk column, because the junk column will have been used as a proxy by someone who did not know what it meant.

Unified profiles are keys. They are not a golden record. Identity resolution does not pick a winning value and does not override source values. If you map two status fields, you have mapped an argument. The profile will point at both. It will not notice that one of them is the standard field nobody fills in and the other is the custom field the business actually uses. Map the one that is used. Document the fact. Do not map both and hope a later formula notices.

#Why the full dump feels fast

Exporting every custom field looks like progress. The workshop ends early. The connector run is green. Six months later the harm is specific. Segment authors cannot tell which field is safe. An agent grounded on "status" picks up the empty standard field and sounds sure about a blank. A marketer filters on a custom flag that two teams define differently, and both teams are surprised by the count. You imported the argument, and now it sits in the profile, where it is harder to see than it was on the page layout.

Quarantine custom fields in three piles before anyone builds a mapping. In the map: used by a named segment, activation, or agent answer, and populated often enough to trust. You establish "often enough" by a count of blanks, not by a feeling. Later: a plausible question, no owner yet. Out: blank on most rows, duplicated under another name, or explained differently by two teams. Out does not mean deleted from the CRM. It means not ingested. The CRM can keep a bad field. Data 360 should not have to.

Name a steward for each field you do map. The steward can say what a value means, and what a blank means. If nobody can say, the field is Out, regardless of how long it has been on the page layout. Tenure is not a definition. A field that has existed for a decade without a sentence is a decade of ambiguity, and ingesting it preserves the ambiguity at a new layer.

The count of blanks, conflicts, and non-person rows belongs before this mapping is trusted. It is the audit to run in the source. A beautiful attribute mapped onto a broken key unifies the wrong people and then decorates them. Fix the key, or exclude the row. Do not decorate first.

#Keys before decoration

Map match keys before you map description fields. Email, phone, customer number, CRM id, account id. Count blanks and conflicts first. The engine does not pick a winning email. Whatever you map is what the profile points at. A phone field full of switchboard numbers, mapped because it was on the layout, will glue a company into one person. You will see it in a sample of twenty profiles if you look. You will not see it in a field-count slide that celebrates how complete the map is.

Decide the grain in the same pass. Person and account are different maps. Do not flatten account revenue, account industry, or account owner onto every contact "for convenience" and then sum them. You will double-count, and the chart will look certain. Keep account attributes on the account. Keep person attributes, including consent, on the person. A segment that needs both should join them on the account id you trust, at the hierarchy level you have named, and the chart title should say which grain it counted.

Prefer the standard meaning of a field over a local nickname where the standard one is actually used. Where the business lives in a custom field and the standard field is empty, map the custom field and write that down in a sentence. "We map Custom Lifecycle, not Status, because Status is empty and Custom Lifecycle is what service edits." That sentence prevents the next project from mapping Status as well, in the name of using standard fields. Standard is a virtue when the standard field holds the fact. It is a trap when it does not.

Consent is a key of a different kind. Map it with the person, with the source and the time, not as a yes or no stranded without provenance. A blank is not a yes. If two CRM fields both claim to be consent, do not average them in the map. Hold the conflict out until a person resolves it, and map a single attribute that already states the stricter rule, documented in a sentence. Hidden reconciliation inside a formula is how a yes leaks through.

#Cadence is part of the map

A column is not fully mapped until you have said how it arrives. CRM attributes that change when a person edits a record are usually a batch. An event someone is waiting on, such as a consent withdrawal that must stop a live send, is a stream. Write the choice on the mapping row. A sheet of field names with no cadence is an ingest you will regret, because both paths are available and the default will be whichever the connector demo used.

One arrival path per attribute, unless you have written how a correction beats the earlier value. Email on the nightly batch and email again on a stream will disagree for a day. The profile points at both, because nothing overrides the source values you stored. Pick the batch for the attribute and the stream only for the event with a waiter. The stream does not get to carry "the rest of the record" so a screen can render. The screen can read the batch profile.

Include deletions and corrections. If the CRM merges two contacts under a survivor rule, Data 360 needs to learn the result on the next load. The profile will not invent that merge. It is not a golden record, and it will not delete the loser for you. The CRM job and the map are a pair. Do the survivor work in the CRM, then map the records you kept. If you map first and merge later, the profile was relating records you intended to destroy. Rebuild the unify from the records that remain. Do not keep a profile that points at deleted ids and call the map complete.

Zero copy is federation, not a latency promise, and it is not a reason to skip the map. Some CRM-adjacent facts may live outside the CRM, in a store you connect with zero copy data federation. You still choose the columns, the key, and the consumer. A federated window onto every column is the dump again, with the bytes left elsewhere. Federation does not tell you the read will be fast enough for an agent in a conversation. If the agent needs the column, measure the path or copy the narrow field onto the batch. Do not federate the CRM's entire reporting schema because the connection was available.

Tableau Next does not replace Tableau. The map is not finished when a workbook can see the fields. The help page says you can expand Data 360 using Tableau or Tableau Next. Analysts should use the tool they already open. A chart that requires the reader to guess which of three status fields was used is a chart of a bad map. Put the field name you actually mapped into the subtitle. If you cannot, you mapped too many.

#Review the map when the second question arrives

The second segment is the dangerous one. It needs two more columns, and it arrives when people are proud of the pipe. Pride is not a mapping rule. Someone will ask to bring the rest now that the pipe works. The pipe working is not a reason. A question is a reason. Add the columns that segment filters on. Leave the piles you marked Later and Out where they are. Update the steward column if the first steward has left. A map whose stewards have all left is a dump with better formatting.

Read the last column in the mapping workshop. It is the list of hopes the dump is designed to satisfy, and none of them are true of the engine. The engine relates what you stored. The map is the decision about what is worth storing.

The wider decisions, what a person means for each use case, how strict the match is, which system owns each attribute, whether the object is copied or only referenced, sit under the map and are expensive to reopen once segments depend on the shape. They are in getting Data 360 right the first time. Do the map as if those decisions have already been said aloud. If they have not, stop mapping and say them. A complete field list is not a substitute.