Salesforce Data Cloud Consent Synchronization

Business Problem

The same email address can exist on multiple Salesforce Lead and Contact records. Relying on a single record can create inconsistent consent decisions when one record is opted out and another is not.

Solution

Built a Data Cloud batch transformation that combines Lead and Contact source data, normalizes email addresses, applies an any-opt-out-wins rule, and maps the result into the Communication Subscription Consent data model for marketing email consent.

Architecture

Business Rule

• If any matching Lead or Contact is opted out, the effective consent becomes OPT_OUT
• Only when all matching Salesforce records are unchecked does the effective consent become OPT_IN
• Consent is evaluated by normalized email so duplicate Lead and Contact records resolve consistently

What Was Built

• Appended Lead and Contact source DLO records into one transform path
• Normalized email using lowercase and trim logic
• Converted Email Opt Out into a numeric flag and aggregated by email
• Used the maximum opt-out flag so any opted-out record wins
• Joined the effective consent result back to each original Lead or Contact row
• Wrote the result to a transformed consent DLO and mapped it to Communication Subscription Consent

Validation

The proof of concept was tested with one Contact and two Leads sharing the same email address. Opting out the Contact caused all three Data Cloud consent records to resolve to OPT_OUT. Unchecking the Contact again returned all three records to OPT_IN because the two Leads were already unchecked.

Next Iteration: Multi-Source Consent Integration (UAT)

A subsequent integration project expanded this consent work beyond CRM to include consent events arriving from a separate survey platform. This is a distinct use case with a different business rule: the latest recorded consent action wins across sources, rather than the initial CRM-only any-opt-out-wins proof of concept shown above.

In UAT, the consolidated transform was validated and populated a Contact Point Consent DMO. A CRM write-back Flow was built and validated but remained inactive pending end-to-end approval and production-readiness testing.

The work demonstrates source reconciliation, cross-platform data transformation, Salesforce Flow write-back design, and careful separation of validated behavior from production activation. Client identities and system-specific configuration are intentionally omitted from this public case study.

Production Considerations

• The current proof of concept uses source refresh plus batch transformation and is not real-time
• Production scheduling should remove the need for manual refresh or transform execution
• Future enhancements can include Salesforce checkbox write-back and phone-channel consent such as Do Not Call