ChatGPT
Claude
Google AI
Copilot
Sales Cloud and Marketing Cloud work together when three decisions are written down. Which system owns the person. Which system owns consent. Which campaigns are allowed to create a lead. Until those exist, a sync is a way for both sides to stop trusting the record.
The failure is a click. A newsletter click creates a lead in Sales Cloud, because every response was mapped and the mapping felt thorough. Sales closes the lead as junk by lunchtime. The close writes back. The marketing score drops. The next week the same person registers for a webinar that was supposed to be a real handoff. Sales sees the last lead, ignores the new one, and says marketing sends rubbish. Marketing sees the closed junk and says sales will not work a good registration. Both are describing the same missing list. Meanwhile a send goes out, because Engagement has an opt-in for that address, Account Engagement has an opt-out, and nobody wrote which flag wins.
These are not one product, and they are not one switch. Marketing Cloud Engagement is the journey and email tenant many teams still mean when they say Marketing Cloud. Account Engagement, formerly Pardot, scores and nurtures on its own user model. Marketing Cloud Next is a different product, closer to the core Salesforce platform. A connection from Sales Cloud to one of them does not connect the other two. A programme that says "turn on Marketing Cloud" is incomplete until it names which one.
Salesforce renamed Data Cloud to Data 360 on 14 October 2025. You may still see the old name in the application and the docs. The name change does not merge these products. Agents are described as answering from CRM data and from Data 360. That sentence does not appoint an owner for the person, and it does not store consent.
Who owns the person
One system creates the person and is the only one allowed to retire them. The other system may update the fields it has been given. A common split is that marketing owns a prospect until a stated handoff, and sales owns the contact once a rep is working the account. Write the handoff as an event: a form you trust, a campaign member that meets a rule, a converted lead. "When marketing thinks they are ready" is not an event. The newsletter click felt like readiness. It was a click.
Write the event so both sides can point at it on a record. The form's name, the campaign's name, the field that flips, the time. After that event, sales may correct the phone number a rep confirmed. Before that event, marketing may correct an email address on a prospect it owns. The direction matters as much as the field. A field with two writers will be wrong within a month, and each team will blame the sync. The sync did what it was told. It was told that both sides could be right.
Fields follow the owner. Marketing does not overwrite a phone number a rep confirmed yesterday. Sales does not silently replace a preference marketing recorded this morning. Put the allowed fields in a short table the admins keep: field, owner, what the other side may do (read, or suggest, or nothing). Suggestion means a value sits for a person to accept. It does not mean a write. The click-to-lead failure started because "create" was treated as a kind of suggestion. Creation is a write. It needs to be on the list, or it does not happen.
Copy the fields the other side is allowed to act on. Leave the rest where it is. Syncing every field feels thorough in a workshop and produces two half-trusted records in the second month. The half-trusted record is the one a rep will not call and a marketer will not suppress, because each believes the other side has already corrupted it. You can see it in the behaviour. People keep a private spreadsheet of the customers they actually believe. The integration is then decorative.
Which system wins for each attribute, when two copies already exist, is the same decision as any other estate. Settle it per field, with a tie-break for an empty value, before the connector runs. The wider pattern is in integration at programme level. A marketing sync that "lets the latest write win" will let a batch import beat a rep's correction, because the batch is newer and meaningless. Recency is a default. It is not a policy. Name the winner.
Consent has one owner
Consent has one owner. That system records the channel, the purpose, and the time. The other system reads the flag. It does not invent a second opt-in because a send needs volume. If Engagement, Account Engagement, and Marketing Cloud Next are all in the estate, name the owner for each purpose. Three flags that disagree are a compliance problem. Another mapping spreadsheet will not fix them.
Purpose is the word that stops the argument. A newsletter purpose and a webinar purpose and a sales-follow-up purpose are three records, even for one person. The owner of the newsletter flag may be Engagement. The owner of the sales-follow-up flag may be the CRM. Write that. A single "opted in" checkbox on the contact, fed by whichever system synced last, is how the opt-out in Account Engagement lost to the opt-in in Engagement. Last write won. The person had said no in the system that was supposed to own that purpose, and the send left from a different one.
The reader systems do not get a local override "just for this journey". A journey that needs volume and finds the flag false does not get to set it true. It skips the person, and the skip is visible to the owner. If that skip rate is a surprise, the list was never the people you thought you had permission to mail. Fix the permission. Do not fix the flag.
Time and channel sit with the flag. A consent row without a time cannot be explained later. A consent row without a channel will be reused for a channel the person did not see. The owner stores both. The copies display both. A copy that stores only true or false has already thrown away the part you will need when someone asks why the mail arrived.
Which campaigns may create a lead
Then write the list of campaigns allowed to create a lead in Sales Cloud. A webinar registration might be on it. A newsletter click might not. Anything off the list can update a prospect inside the marketing product and stop there. Leads that appear from every click get closed by sales, and the next integration meeting is an argument about lead quality that is really an argument about this list.
The list is short on purpose. Each line has a campaign, or a campaign type, the event that counts (registered, not clicked; attended, not invited), and the fields that ride along. A registration may create a lead with name, email, and the campaign. It does not bring the entire prospect record, the score history, and every preference. Those stay with the owner. The lead is a handoff, not a clone.
Write what sales is allowed to do in return. Close as junk is a real outcome, and it should update the marketing product as a fact about that lead, not as a suppression of the person. A junk lead from a click is evidence the click should not have created a lead. It is not evidence the person may never be mailed, and it is not evidence the next webinar registration is junk. Map the close to the campaign, not to the human. The failure in the opening happened because the close was applied to the person, so the good registration inherited the bad click.
Review the list when someone adds a journey. A new journey is a change to the allow-list, not a default include. The person who owns the list, named, accepts or refuses the new line before the journey can create anything in Sales Cloud. "We will tidy the leads afterwards" is how the junk close becomes the integration. Tidy is not a design.
What Data 360 does not decide
You can bring campaign responses and CRM records into Data 360 so a person is visible across sources. Salesforce describes agents as using that data beside CRM data. Putting both records in Data 360 does not choose which value wins, and it does not choose who may email the person. Make the three ownership decisions in the systems that send the mail and hold the pipeline. Unify after that, if you still need the combined view.
A unified profile that shows both the opt-in and the opt-out is a useful warning. It is not a ruling. If a journey or an agent reads that profile and picks a flag, you have added a third writer. Keep Data 360 as a place to see the disagreement. Let the owning system correct the copy. Do not let a segment, built because the profile looked complete, become the consent decision by accident.
Naming the product is part of the test, not a footnote. A sandbox refresh of Sales Cloud will not give you Engagement, Account Engagement, or Marketing Cloud Next. How to test the sync without pretending those tenants came along is in testing multi-cloud integrations in a sandbox. A test that only moves the CRM lead, and never touches the marketing tenant you named, has not tested this integration. Say so.
If you cannot point at the owner of the person, the owner of consent for each purpose, and the campaign list, you are not ready to integrate. Build those three pages first. The connector is the smaller piece. It will faithfully copy a bad decision in both directions, and then both teams will be right to distrust the record.
The first month
Week one is the three pages, with the people who send the mail and the people who work the pipeline in the room. Name the product. Name the handoff event. Name the purpose behind each consent flag. Write the campaigns that may create a lead, and what a junk close is allowed to update. Week two is the field table: owner, and whether the other side may read, suggest, or nothing. Leave every other field where it is. Week three is one campaign on the list, running into a non-production tenant you have named, not into production because the CRM sandbox happened to be free.
Read the leads that appear, and the leads that should not have appeared. If a click created a lead, the list is wrong. If a registration did not, the list is also wrong. If a flag disagrees across products, stop and name the owner before anyone sends. Do not open a workshop to map more fields. The fields were never the gap. The owners were.
