I am currently creating multiple Journey's in Journey Builder, and was under the impression that once a subscriber completed the Journey they would be able to re-enter it regardless if 'Contact Entry' is set to Single or Multiple. I have not been able to successfully accomplish this.

I'm using a Fire Event in Automation Studio to inject the users. This is working as expected, as they enter the Journey and complete one of the routes. But any following Fire Event will ignore these users entirely, even if they still meet the entry criteria.

To test, I added a few records using Contact Builder into the Data Extensions, and these new records would be the only ones added. Looking at the Event History for my entry trigger, it shows neither rejected or accepted for the users that already completed the Journey - they are ignored entirely.

Is this typical behaviour or is there something I am missing? Any help is appreciated, thank you.

1 Answer 1


This sounds like a "high water-mark" issue. Was new data added to the data extension? If not, the Interaction or Fire Event activity may be running as intended, but not detecting new rows because they were not added.

Journey Builder tracks the last event processed for the event source data extension to prevent individual events from being injected into an interaction more than once. This is known as the "High Water Mark." When an event is run, only records in the event source data extension above the High Water Mark will be processed. Records below the High Water Mark will be ignored.

This becomes problematic if an event source data extension has a primary key set on the field related to Subscriber Key. If an import or query activity is updating records in the event source data extension, they will not be assigned a new row in the data extension. This means that for contacts who may now meet filter criteria for the trigger, but who did not on previous runs of the entry event, they will still not be injected since they fall below the High Water Mark.

In order to avoid issues with the High Water Mark, it is recommended as a best practice to either use no primary key on the event source data extension, or to use a primary key other than Contact Key, Email Address, Mobile Number, or Device ID. You can also use an "overwrite" method for your import/query into the Event Source Data Extension.

  • 1
    Hi Jeremy, thank you very much. I actually stumbled into that link earlier this morning by chance and that is definitely my issue. It's an inconvenience for sure, but there are slightly messy workarounds that I can use to get around this. Thanks for the help! Commented Feb 15, 2016 at 18:55
  • Actually, my workarounds will not work as desired thanks to this nice bit of info..."In the case of duplicate records in a data extension, the first record encountered for a contact key will be used for personalization strings and decision splits." Not fun :/ Time to try and find workarounds for the workarounds! Commented Feb 15, 2016 at 19:01
  • Hi @AnonWonderer - Could you figure out the workaround of this ? I am stuck at the same point right now
    – Maneesh
    Commented Aug 17, 2016 at 0:12
  • Oh boy it's been so long... in my context users could have entered the Journey twice (as a guest and then as an account owner). So I basically made my Journey Source DE have SubscriberKey AND hasAccount as the Primary keys. That way when they made an account, they would be added into the Journey DE with a different primary key pair. To resolve the personalization strings from taking the original contact records values, I ran a query to update the original contact record in the Journey Source DE with the data of the new contact entry. Commented Aug 17, 2016 at 23:27
  • Kind of convoluted and probably outdated at this point - I would suggest checking out the new 'Audience' Entry events as they don't have a high water mark, and how Decision Splits can be based on 'Event' or 'Contact' data to resolve wrong personalization / splits. Commented Aug 17, 2016 at 23:28

You must log in to answer this question.

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