Forum Ambassador
Hi all. Looking for input from anyone who has done B2B with many-to-many account–contact relationships.
Setup:
• B2B only; Sales Cloud is the only data source
• Contacts are linked to multiple Accounts via Account Contact Relationship (many-to-many)
• The same person can have a different role and relevance at each account
Requirement:
If a contact is related to two accounts that are both in a send's audience, they should get two emails, one per account. Each is personalised with that account's data (company name, account-level figures, etc.).
The tension:
In MC Next, segments and data graphs are anchored on Unified Individual, and identity resolution collapses the person into one profile. That's what we want for consent, which is keyed on the email address. But it seems to work against "one email per relationship". It also makes account-level merge fields ambiguous when one person has several accounts in the data graph.
Questions:
Has anyone delivered one email per account relationship in MC Next? Which pattern did you use: separate segments or flows per account, iterating over Account Contact Relationships in a flow, or something else?How do you make the data graph deterministic about which account's data renders in a given email?Any identity resolution tips for this case, e.g. keeping Contact-level identity versus matching on email?
Happy to share back what we land on
#Marketing Cloud #Sales CloudHi @Lukas Lunow
This gets easier to create an approach, when we look at how each piece works underneath. Not done personally, but this is how i would approach this:
- Sending works per row, so create the rows you want sent. MC Next sends one email per record that reaches the send step. If you want one email per account relationship, you need one row per Account Contact Relationship. Build a DMO with a Data Transform, keyed on the ACR Id, with the Contact Id, email and the account fields you need (company name, figures, role) on that row. Two relationships means two rows, which means two emails.
- Personalization reads from the record being sent, so put the account data on that record. The data graph gets ambiguous when one person has several accounts attached, because nothing tells it which one to pick. If each ACR row already carries its own account data, the merge fields just read from that row and the output is deterministic.
- Identity resolution is for the person, not the relationship, so let it do only that. Unified Individual exists to collapse the same human into one profile, which is exactly what you want for consent on email. Keep Contact Id as a Party Identification and match on email. Keep account-specific attributes off the Individual, so they never compete in the unified profile. Consent and suppression stay at the person level, and the send grain stays at the relationship level.
The main thing I’d validate is how cleanly MC Next lets you send off a relationship-level DMO while still checking consent on the linked Unified Individual. We can prototype with one contact on two accounts before rolling out.