How to implement consent management across Salesforce Data Cloud

A send leaves on a stream just after lunch. The person had withdrawn consent that morning in the preference centre. The withdrawal is in a file that will load tonight. By the time the flag arrives, the destination has already accepted the row. The CRM still says yes, because an old import said yes, and the segment definition never looked at the preference centre. Unification had already related the two profiles. Someone assumed the profile now "had" a single consent. It had two assertions. The activation saw the convenient one.

#Consent is a field, not a finale

The product is Data 360. Data Cloud was rebranded 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." You still ingest streaming and batch data, then harmonise, unify, and analyse it. Consent has to be one of the things you ingest. A consent module that marketers admire after the segment is built is too late. The segment should have been unable to publish without the flag.

Model the smallest set of purposes you will actually enforce. Advertising. Email. Phone. Add a purpose only when a real activation needs it, and retire a purpose that no activation has used in a quarter. An unused purpose still attracts arguments, and arguments are how a blank gets interpreted as a yes. A catalogue of twenty purposes, half of them unmapped, gives you arguments rather than a filter. Each purpose needs a value, the system that asserted it, and when. A bare true or false with no source cannot be defended, and it cannot be repaired when the other system disagrees. "True" from a spreadsheet in 2019 is not the same fact as "true" from a preference centre yesterday. The attribute has to be able to say which.

Store it on the person, not on the account, unless you have written a lawful basis for the account to speak for the person and you can point at that writing. A buying group does not consent on behalf of a colleague by being in the same segment. An account plan can exist for a seller while a person on that account stays out of the activation. Collapsing those two extracts because the lawful count looks small is the failure. A small lawful audience is the result.

#Carry it into every activation

A segment definition that does not mention consent is incomplete, even if the count looks right. Put the filter in the segment, and check it again at activation if the destination can receive a broader set than the segment intended. People get added between those two steps. A withdrawal can land between them. The flag has to win both times. One check is a count you admired. Two checks are a control.

Write the refusal list where the operator can see it. No send on a blank. No send on a conflict. No extra attributes while you are here. The destination receives the identifier it needs and nothing you would be ashamed to read back to the person. A phone number added because matching looked thin is a new purpose. If the purpose was email, the phone stays off the file.

The same rule applies to audiences you describe as predictive, lookalikes, or account-based. The technique does not create a purpose. If the person has not consented to that use, they stay out. The advertising case, including the temptation to drop the refusal list when the accepted count disappoints, is segments sent to an ad destination. The refusal list is the same list. A new channel does not get a quieter version of it.

Zero copy is federation, not a latency promise, and it does not carry consent by being connected. If the flag lives in an external store, zero copy data federation can leave it there. The activation still has to read it, in time, under a failure behaviour you have chosen. If the federated read fails, the safe behaviour is to hold the person out, not to send because the flag could not be fetched. "Could not check" is not a yes. Measure that path before you depend on it. Do not brief a speed you have not timed.

#Disagreement is not an average

Two systems will disagree. The CRM says yes, the preference centre says no, or the reverse, or one of them is blank. Do not average. Do not take the newest stamp without a rule that says why newest is right for that purpose. Do not let the segment owner decide in the campaign brief. Until a person resolves it, the stricter flag stands. Stricter means the person is held out.

Newest-stamp-wins feels like a policy because it is easy to automate. It is wrong when the newer stamp is a bulk import that never asked, and the older stamp is the form the person submitted. It is also wrong when a normalisation job touches the row and updates a system date without changing the choice. Recency is a candidate rule for some attributes. Consent is the attribute where it most often is not. Write the rule you actually mean. If you cannot, hold the conflict out. Holding out is a complete policy. Guessing is not.

Log the conflict as its own count. It is an operational queue, not a data-quality footnote. Name who is allowed to close it, and what evidence they need. A note from the customer. A fresh form. Not a target for the campaign. A bulk "set to yes" to clear the queue is an incident. Treat it as one the day it is proposed, including when it is proposed as a temporary step to hit a date. Temporary yes-fills survive. They become the attribute.

Identity will not save you here. Unifying two source profiles does not merge their consent into a single winner. Unified profiles are keys. They are not a golden record. Identity resolution does not pick a winning value and does not override source values. You still have two assertions. The activation rule has to see both, or it has to see a purpose-built attribute that already applied stricter-wins. If you build that attribute, document it in a sentence a marketer can read aloud. Hidden logic is how a yes leaks through a formula nobody re-reads.

#Speed, or the withdrawal is theatre

If you activate on a stream, a withdrawal that arrives only in tonight's batch is a full day of sends you said you had stopped. The withdrawal path has to be at least as fast as the activation path. Test it. Change a flag for a named test person, in the source of truth for that purpose, and watch the segment and the destination. Write down the minutes. If you cannot run that test, you do not have consent management. You have a field.

Batch remains the right path for history and for repairs. Use it. Do not leave the only copy of a withdrawal on the slow path while spend is on the fast one. Streaming and batch are both legitimate. Consent picks up whichever one matches the risk, not whichever one the first connector demo used. A repair that fixes a wrong yes can travel on the batch, as long as the stop that prevents the next send is fast enough for the send you are actually running. Say both cadences on the mapping row. A sheet of purposes with no cadence is a policy PDF.

Tableau Next does not replace Tableau. A dashboard of consent rates is not the test. The test is the named person leaving the destination. Put the minutes from that test where the operator will look, in whichever tool they already open. A new charting surface will not make a nightly file govern a lunchtime send. The help page lets you expand Data 360 using Tableau or Tableau Next. Neither one is the withdrawal path.

#The four numbers that are the programme

Review four numbers on a cadence you will keep. Sends. Refusals. Conflicts open, and how old the oldest one is. Withdrawals that missed the window, meaning the flag changed and a send still went. Those numbers are the programme. A policy document is not. If refusals are zero for a month, you are either unusually clean or you are not applying the filter. Believe the second until a sample shows the first.

The sample is twenty people you sent and twenty you refused. Read the flag, the source, and the time. If a refused person is in the send, the filter lost. If a blank is in the send, the filter lost. Do this before you argue about creative. Creative is not why the wrong person was in the file.

Name an owner for the conflict queue and an owner for the withdrawal test. They can be the same person. They cannot be a committee that meets after the campaign. When a new source of consent appears, treat it as a change to the rule, not as another column. A new source is how a stricter flag gets ignored, because the segment still points at the old column. Re-run the named-person test when the source changes. The test is cheap. The send you cannot claw back is not.

The last row is the one unification makes worse if you do not expect it. The profile looks singular. The consent is not. Keys do not vote.

The design under those rows is the same design as any other Data 360 attribute. Which system is the source of truth for this purpose. Whether you copy the flag or reference it. Who owns the rule when a new source arrives. Those choices are cheap before the first send and expensive after a withdrawal misses a window. They sit with the other pre-ingestion decisions in getting Data 360 right the first time.

#What you do not automate

Do not automate a yes. Do not let a segment definition override a conflict because the campaign has a date. Do not inherit consent across a household, a domain, or a buying group because the match rule related the records. A match is not a signature. The person who opts out stays out, even when the profile points at someone who opted in. If your stricter-wins attribute does not see that case, it is not finished.

Review the four numbers. Re-run the test when the path changes. Keep the refusal list shorter than the ambition of the campaign. The ambition is a briefing. The list is the control.