Someone recently asked me why a one-to-many relationship exists in Contact Builder. And I think that's a very good question (also why there is a many-to-many relationship too). The ability to create these types or relationships has existed since Contact Builder was introduced, over five years ago.

The contact model (in Contact Builder) is pretty much exclusively used by Journey Builder (except for some internal platform purposes, like mapping relationships between the Contact Record to email Subscribers, mobile Contacts, etc).

If I have a one-to-many cardinal relationship to a 'Products' Attribute Set in Data Designer, and there is a single product record for the Contact, and I use that Attribute in a Journey Builder Decision Split Activity, then the Contact is routed through the correct branch:

However, if I update the Product DE (which is the linked Attribute Set in Data Designer) to include the following fields for a given Contact:

Id,Product
0031N00001IyHRiQAN,Banana
0031N00001IyHRiQAN,Apple
0031N00001IyHRiQAN,Carrot

Then when I inject the Contact back into the journey multiple times, they are routed through the first branch in the journey each time:

This behavior is understandable, as there is no concept of a one-to-many relationship in Journey Builder Activities.

However, this does beg the question: why can you create one-to-many relationships in the first place? There's no Marketing Cloud application that supports one-to-many (or even many-to-many) contact model relationships that I'm aware of.

Data Designer includes a library of impressive looking Attribute Groups for different use cases, like this one for 'Travel Bookings':

travel bookings attribute group

But I'm can't figure out how anyone is able to actually use this Attribute Group, or any one/many-to-many relationship in the contact model. Can you?

Update

Gortonington suggested in a comment that this might work if there are multiple conditions on a filter criteria. I've tested that, where my Product Attribute Set still contains the three records listed above (see earlier code block).

I created an additional branch in my journey for all products, where the filter criteria is:

Product equals Banana and Product equals Apple and Product equals Carrot

However, the Contact is still routed through the first branch, so that doesn't work.

  • 1
    I wonder if a way to utilize this is to add extra conditions to the split. Have it be (Product = "Apple" AND Product = "Banana"). These would have to be above the individual conditions though as Attribute splits are like CASE SQL statements and once it finds a match (top to bottom) it will exit the conditional, regardless of future matches. I will try to grab some time to test this out and report back. – Gortonington Oct 25 at 13:18
  • That's a good idea. I've tested this and that doesn't work either. I do have an answer though. I will include the results of this test in my question. – Eliot Harper Oct 25 at 20:40
up vote 3 down vote accepted

I've asked around some Salesforce contacts to try and get to the bottom of this. It appears that this support for many-type relationships as created with good intentions, but they have never built this out further.

However you can view this relationship data against the Contact in All Contacts. For example, here is the Attributes page for the Contact in my question:

Attributes

Here you can see the multiple records related to that Contact in the linked Attribute Set. I can't really see how this would be useful (as you need to open each individual Contact in Contact Builder to see this data) and this data relationship can't be used elsewhere.

I'm concerned that users would make assumptions that these many-type relationships actually serve a purpose in the data model, when they don't.

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.