Follow up on the recent thread about Contact Point Emails and Marketing Cloud Next consent (the one where François pointed to the multiple email addresses article, that article matches my use case closely: How should Contact Point Emails be | Salesforce Trailblazer Community).
My situation is on Contacts rather than Leads. Stakeholders can have several email addresses, and the number is not fixed. Some have one, some have three or four, and (although it'd be rare) it can grow over time. So adding a fixed set of custom email fields on the Contact object (Second Email, Third Email etc) does not really work for us, as we cannot predict the ceiling.
What we already have is core ContactPointEmail records against each Contact, which handles any number of addresses cleanly. The problem is these do not seem to be recognised by the consent layer. Looking at the Contact Point Email DMO in Data Explorer, the rows sourced from the standard Contact mapping have Party equal to the Contact Id, but the rows sourced from ContactPointEmail have Party equal to the core Individual Id, since that is what ContactPointEmail.ParentId points to. So they do not line up with the Individual DMO rows, which are keyed on Contact Id.
My question: is it a supported approach to use a Data Transform to read the ContactPointEmail data and write it into a DLO mapped to the Contact Point Email DMO, with Party set to the Contact Id and a synthetic primary key (similar to the CONCAT approach in the article, but sourcing from real ContactPointEmail records instead of custom fields on the Contact)?
That would give us an unlimited number of addresses per person while still following the Party = Contact Id convention the consent layer expects.
Or is there a reason core ContactPointEmail records are deliberately not wired into the consent model, and the custom-field-plus-DLO pattern is the only intended route?
Also, does Marketing Cloud Growth generate consent rows for custom Email-type fields on Contact, or only standard fields?
One alternative I considered and would rather avoid is creating multiple Contact records for the same person with different email addresses. Apart from the obvious data quality problems, I do not think it would even work, our identity resolution matches on normalised email only, so two Contacts with different addresses would resolve as two separate Unified Individuals rather than one person with two addresses. Happy to be corrected if I have that wrong.
Any guidance on the intended pattern here would be appreciated.
