Use cases for one-to-many and many-to-many relationships in Contact Builder

I've asked around some Salesforce contacts to try and get to the bottom of this. One-to-many relationships from Contact Builder are only applicable in Audience Builder (as Audience Builder uses these relationships).

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:

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 Journey Builder.

Have you tried setting this up to run in series, rather than parallel?

As someone mentioned in another answer, Decision Splits act like CASE statements; the first criteria met by the subscriber will be the path they get sent down. You can't send a customer down multiple paths without having them re-enter the journey, and if they keep meeting the criteria they'll keep going down the same path. That's logical.

If your use case is to send a subscriber a comms piece for every one of a given set of Products, then try setting it up as a series of Decision Splits, where a Product entry triggers a comms piece, and people who don't meet the criteria go to a Join that bypasses that comms item and moves on to the next Decision Split.

You can split/nest Product types in some fun ways within Decisions Splits to avoid sending specific combinations, or managing priorities, or whatever else you want to do.

Also, if you want to use a parallel model and don't want people to go down the same path every time, look into using an Update Contact step and a Journey History DE to manage this. It's simple, effective and very extensible, and gives you a useful history record to boot.

We do something similar to what you've outlined, and have not had any problems using a 1:M model to manage a multitude of tasks withing one central Journey.

Cheers