1

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

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
6
  • 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 Dang - formerly Slabina
    Nov 28, 2016 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, 2016 at 17:24
  • 1
    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 Dang - formerly Slabina
    Nov 28, 2016 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, 2016 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 Dang - formerly Slabina
    Dec 1, 2016 at 21:17
1

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

Improve this answer
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.

Improve this answer
2
  • 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, 2017 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 Dang - formerly Slabina
    Aug 21, 2017 at 9:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .