Decision Split With SF Entry Event Not Working As Intended

Question

I've got a journey being populated by an SF Entry Event from the Lead Object. Later in the journey, I want to check for updates to a status field on the Lead object using Contact data. Unfortunately, though the decision split is set up correctly, contacts seem to be processed at random regardless of status (most go to the remainder even though status is the same for all).

I've added wait steps to ensure that my synced DE's have 45 extra minutes after their poll rate to sync, have added additional criteria to the split to attribute compare where Lead ID equals the Lead ID field in the entry data, and have triple confirmed the criteria each user is getting.

I've seen posts on here related to this issue but it says that it was resolved in a SFMC update from 2017, so it should no longer be an issue.

Anyone have any ideas short of building my own decision split activity?

Answer 1

On my end I can confirm that Decision Splits do work properly even when using SF Entry Event and utilizing Contact Data path with the Decision Splits.

That being said, the official documentation is contradictory on how this should actually be configured.

What seems to be the 'correct' way is described with a scenario on the Attribute to Attribute documentation page.

Attribute to attribute comparison is useful when a single contact can enter a journey more than once. Or, you can compare a journey data attribute to a contact data attribute to determine if a change occurred between time of entry and current time. Drag the contact data attribute into the filter first, then drag the journey data attribute into the filter on the other side of the operator.

Meaning while the attribute comparison can be configured both ways (Journey DE Data = Contact Data) and (Contact Data = Journey Data) then the right way is doing the ID check by utilizing Contact Data first, and comparing Contact Data LeadID with LeadID from the Journey. Then adding other criteria points through the Contact Data after it, like Lead Status.

Another point that can often mess up the Journey Builder processing is the high water-mark issue, in case you have removed any existing entries in the Data Extension used in the Journey.