0

Scenario

I created a journey with a Contact Data entry event that is triggered via the API. A subscriber should be able to be injected multiple times and the values in the data extension are updated while the subscriber is in the journey. The updated values should determine the path the subscriber follows.

Setup

As changed data needs to be evaluated and the contactkey cannot be used as primary key, I added a random id as primary key and created an attribute group for the data extension in Data Designer. The data extension is linked to the contact's contactkey using a one-to-many relationship as a contact should be able to enter the journey multiple times.

In the journey I'm using a decision split that is configured to use contact data from the created attribute group and has two branches (as it checks a boolean value).

Problem

For multiple entries the decision split doesn't evaluate correctly and always leads to same branch (value equals false). I suppose the problem is that journey builder doesn't use the primary key to identify the correct row in the data extension. Is there any way to make sure the row is matched using this id and not the contactkey as this leads to some strange behaviour as described here: https://salesforce.stackexchange.com/a/140904/36218

1

I had faced the same issue earlier. Refer to the Link for the resolution to the issue.

For contact data to work, both subscriber key and contact key should be same.

  • Thanks for your reply, but I already found your question and unfortunately this isn't the same problem. The used id in my case cannot be used as subscriber key. Other decision splits (for salesforce data event journeys) work fine as everything is linked in the data model correctly and the subscriber key in my setup is the contact id of the salesforce contacts. The id used in this journey isn't stored in any other salesforce object, etc. and is just used to identify records in this data extension, to ensure updates are possible for multiple records for the same subscriber (needed for api-call). – Markus Slabina Nov 28 '16 at 16:14
  • From the input i got from salesforce, only the subscriber key is injected into a journey builder. In yor case, primary key is a random id and is different from subsciber key. During journey builder decision activity, system tries to fetch the primary key from the subscriber key and since the relation is not 1:1, there are many records and the evaluation criteria fails. – Ganesh Kumar Nov 28 '16 at 17:24
  • In fact that is the problem, but I don't think setting an ID that doesn't represent a unique subscriber (which then isn't a subscriberkey by definiton) as subscriber key just as a workaround for this behavior is a desired solution. The journey-setting "re-entry anytime" wouldn't make sense in this case. Furthermore it is possible to evaluate decision splits correctly for multiple entries with the same subscriber key, as this can be achieved when connecting another object to the dataextension, which i've done when using sf data events. But in this case there is no sf-object using this id. – Markus Slabina Nov 28 '16 at 18:00
  • This is a current product limitation and what i had suggested is a work around suggested by SF Support team. Update if you have got a alterante solution. – Ganesh Kumar Dec 1 '16 at 13:56
  • It's unimaginable that such a important feature isn't already possible out of the box... I just tried the workaround you suggested, but somehow even this doesn't work properly. If I find a solution that works and doesn't mess up the subscribers with using different ids for same subscribers, I will share it with you. – Markus Slabina Dec 1 '16 at 21:17
0

Using a custom journey builder entry event with an additional transaction key enables extended settings for the journey using this event. When using such a custom event, a unique id is used in conjunction with the contact key which solves this problem:

Transaction keys combine an ID value that Journey Builder generates and a unique contact attribute value to create a wholly unique identifier. This unique identifier is observed by all contact filters in the journey, including filters in the entry event and decision split activities. This prevents contacts in the journey from following the unintended path when their ContactID still matches current entry or decision split criteria due to a previous transaction.

The contact attributes available for creating a transaction key are ContactID and ContactKey. Transaction keys are commonly used when a journey's entry event is fired via API.

Further documentation can be found here:

EDIT: I created an example event, which can be found on github: Salesforce Marketing Cloud - Custom Event with Transaction Key

0

There is another way to "force" the decision part work in the way you'd want it to. I'm assuming that your API call passes that random ID that you generate which should allow you to do the attribute-to-attribute comparison between journey data (random_id) and contact data (random_id in the attribute group) as additional criteria in decision split. Would be a bit easier to help if you'd share elements of your contact schema.

  • Markus I'm failing to see the relationship of the mentioned bug to your use case, apologies. The way I read your challenge is pure 1-to-many selection while this bug is about having same DE linked through multiple paths in contact model. You on the contrary have a dedicated attribute group. – Vlad Aug 21 '17 at 9:51
  • Even though, using transaction keys in the entry event (as described in the accepted answer) is the way to go according to salesforce marketing cloud documentation, so I'll stick with this solution, but thanks for your input! – Markus Slabina Aug 21 '17 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.