Please find below the findings of a recent investigation into Journey Builder Contact re-entry – where the concurrent journey injection relates to child records such as Opportunities or Purchases.
Problem
Where Journey Entry occurs at a Child-object level (Opportunity, Case or Purchase as examples), a given Contact may enter a Journey multiple times; the journey injection relates specifically and exclusively to the child record not the parent Contact.
When Contact Data attributes are referenced (by filter expressions) across one-to-many relationships there are no implicit filters applied that ensure that only the relevant Child-object record is referenced, i.e. the record that initiated the journey entry. Instead the first Child-object record (related to the Contact) that passes the filter conditions for a configured path will be utilised. This means that any child record (for the Contact) could drive the flow through each decision split within the Journey.
Solution A. Salesforce Data Events
Note, auto-generated Data Extensions related to Salesforce Data Event Entry Sources are created with all fields set to nullable, apart from the Primary Key (Primary Object ID).
A.1 Id field on the related Salesforce (Child) Object is the Foreign Key to the related Contact Data.
e.g. Entry Source = Purchase Data Extension (PK is Purchase Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can go ID field to ID field with an attribute to attribute comparison (which requires non-nullable fields).
In Journey filter expressions (specifically Decision Splits) add filter criteria to every path:
1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Object ID field (Primary Key)
The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.
2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.
A.2 Non-Id field (other relationship field) on the related Salesforce Object is the Foreign Key to the related Contact Data.
e.g. Entry Source = Payment Data Extension (PK is Payment Id). The required Contact Data for filter conditions exists in Purchase__c_Salesforce Sync DE. Here we can’t go ID field to ID field instead the nullable FK field Purchase__c is the key into the Contact Model; being nullable an attribute-to-attribute comparison won’t work.
Link the auto-generated Entry Source Data Extension to the related (Synchronised or Standard) Data Extension with a new relationship in Contact Builder (Data Designer > Sales and Service Cloud Attribute Group).
In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:
1) Journey Data > Event Source DE > Primary Object ID field
equals (Attribute-to-Attribute) Contact Data > Event Source DE > Primary Object ID field
The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.
2) Add subsequent Contact Data filters by selecting the Entry Source DE and navigating the new relationship added to the Synchronised Data Extension.
Solution B. Automation Studio Audience
In the Journey filter expressions (specifically Decision Splits) add filter criteria to every path:
1) Journey Data > Event Source DE > Foreign Key field (Could be the Primary Key field or any other field that holds the foreign key identifier value)
equals (Attribute-to-Attribute) Contact Data > (Synchronised or Standard) DE > Primary Key field (i.e. Primary Object ID)
The above ensures that the Contact Model filter references are restricted to the specific record that initiated the journey entry.
2) Add subsequent Contact Data filters using the target DE from (1) as the point of origin.
Additional Considerations
1) Journey Data returns the specific Entry Source DE record that initiated the Journey and provides the only means to establish a fixed reference for this record into Contact Data.
2) Exit Criteria can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level.
3) The Update Contact Activity can’t make reference to Journey Data and as such can’t be applied unless Journey Entry is at the Contact level not Child-object level. This activity will update all child records for the current contact in the target data extension.