Confirm use of synchronized data extensions in attribute groups

Question

hoping someone can confirm if my understanding is correct on a few points:

1. when setting up synchronized data extensions in Contact Builder, these all automatically create an attribute group? The attribute group is a way of linking data extensions that are connected via look up field in Salesforce or something?

2. Resulting attribute group can be used for journey builder decision splits?

3. if a new relationship between synchronized data extensions is needed to set up decision splits in a journey, Marketing Cloud no longer allows users to link synchronized data extensions in Data Designer, correct?

4. to link synchronized data extensions manually, we must create a "duplicate" of the synched DE via SQL query, which can then be used to link to other DEs in Data Designer?

5. if using the automatically generated attribute group created when we set up synched DEs, and I set up a decision split in journey, I'm getting the "At least one attribute in this filter criteria could produce multiple matching values. By default, Journey Builder uses the first matching value. You can use attribute-to-attribute comparison to determine the right match" message. Is this message/issue related to why Salesforce eliminated the ability to use synched DEs when linking data extensions in Data Designer? This is still an issue because users have the ability to use these system-created attribute groups of synched DEs?

Answer 1

You are correct that, when you synchronize the selected objects from SF, that a new attribute group is created with the object model present in SF for the objects you have selected. To my knowledge this is not configurable in MC (with good reason) since allowing you to configure the schema on the MC side could completely invalidate current/future data relationships that are being defined in SF.

Also, which you've already highlighted in your question, you can use an attribute comparison to ensure that you are accessing the correct data from the object model within your decision splits. The message you are seeing in the decision split configuration is due to the fact that your criteria could produce multiple matches since you are using fields that have a one-to-many relationship. Using an attribute comparison should get you around this issue.

If the above still doesn't meet your requirements, and you are unable to make your SF model more MC friendly, then you can always run automations to generate whatever data you want for a given journey and then link your newly created DE to the entry source on a given field.