Journey Builder Salesforce Data Entry - Is there an object level limit for filter/entry data?

Question

I cannot find it in the documentation, however I recall that there might be a limit to the objects one can access, as maximum 3rd level relationship with the primary object selected in the entry, in the filter and data section of the entry? Is this the case?

e.g. If I select Contact as Salesforce data entry

method: is created

filter: when field X on Object 4 = Active

data entry: Field X, Field Y from Object 4

Contact > Object 1 > Object 2 > Object 3 > Object 4

Will this work? or I will need to use SQL to populate a DE before adding to the journey to access the 4th Object

Answer 1

Use SQL to pre-process.

• It's way easier to debug if selection and journey path are separate parts you can take apart.

• It scales better in high numbers.

• Also, what you want does not work within Journey Builder, you have only directly related objects to pick your filter criteria from.

I am clicking through a generic example for you to illustrate:

• CampaignMember
• Is Created

Filter Criteria shows:

• Campaign
• Account
• Contact
• Lead

forget about the customization that I blurred, let's focus on standard object relationships:

Campaign member connects Accounts / contacts / leads to Campaign (it's a junction object in between).

So those are the "neighboring" objects to CampaignMember. Now click on e.g. Contact, and the path ends. You cannot pick any more related objects, just fields on Contact itself.

E.g. you won't see User, which would be one connection away (e.g. every Contact has an owner, stored in the User object). So while you still have access to the User ID that you can find directly on the "neighboring objects", (CreatedBy, LastModifiedBy, LeadOrContactOwner), this is always just the ID present on the "neighboring objects" that is used in the lookup relationship between e.g. Contact and User.

You do not have access to fields on User, e.g. Username.

If you are one or two relationships short, maybe it's still worth trying to close the gap with an AMPScript lookup in the emails, but the initially stated points would still lead me to suggest SQL to begin with. I'd keep my journeys simple.