Concurrent entry is a journey setting that controls whether the same user can be active in a journey more than once at the same time.By default this setting is off. A user can only be at one point in a journey at a time, which is the correct behaviour for most journeys. Enable concurrent entry only when you have a specific need for multiple independent instances of the same user to run through the same journey simultaneously.
This is a non-default, advanced setting. For most journeys — onboarding, re-engagement, suppression — leave this off.
When concurrent entry is off (default), a journey enforces one active instance per user. If a user is already in the journey and a new trigger fires, that trigger is held until the current instance has exited and the re-entry window has passed.When concurrent entry is on, each new trigger creates a fresh, independent instance for that user immediately — regardless of whether they already have an active instance. Each instance runs with its own state, timing, and destination output.
Concurrent entry off (default)
Concurrent entry on
One active instance per user at any time
Multiple active instances per user allowed simultaneously
New triggers held until current instance exits
Each new trigger starts a fresh instance immediately
Recommended for profile-based journeys
Recommended for event-driven or multi-context journeys
High-frequency independent event forwarding — Multiple distinct events for the same user fire in rapid succession and each must be forwarded to a downstream destination without any being dropped or queued behind another.
Multi-context user identities — A single user identity in your data represents more than one relationship, account, or subscription, and each context needs to progress through the journey independently.
Parallel data processing flows — Each incoming data signal for a user carries its own payload that must be enriched, transformed, and sent separately — rather than being merged or deduplicated with other signals.
Onboarding journeys — A user should move through onboarding once in a single controlled sequence.
Re-engagement campaigns — Sending the same re-engagement message to a user multiple times simultaneously is unlikely to be the intended outcome.
Suppression journeys — Concurrent entry can interfere with suppression logic — one instance may trigger suppression while another is still progressing through earlier nodes.
Any journey where duplicate communications are undesirable — If receiving the same message more than once simultaneously would be a problem for your users, leave concurrent entry off.
Concurrent entry is configured during journey creation in the settings panel.
1
Click Create Workflow
From the Journeys listing page, click Create Workflow to open the journey creation flow.
2
Set Allow user to re-enter the journey to Yes
The concurrent entry option only appears when re-entry is enabled. Set re-entry to Yes first.
3
The Allow concurrent entry? field appears
Once re-entry is on, the Allow concurrent entry? field becomes visible directly below it. No is selected by default.
Create Workflow settings panel with re-entry enabled and concurrent entry set to No (default).
4
Select Yes if needed
Selecting Yes enables concurrent entry. An inline warning appears confirming that users may receive multiple simultaneous communications from this journey.
Concurrent entry set to Yes, with the inline warning 'May cause duplicate communications — verify before publishing.'
5
Complete your journey setup and publish
Configure the rest of your journey and publish when ready.
Click the ? icon next to the Allow concurrent entry? label to expand an inline help guide explaining when this setting is appropriate, without leaving the settings panel.
Inline help expanded from the ? icon next to Allow concurrent entry?
You can change the concurrent entry setting on a live journey at any time.
1
Open the journey in edit mode
From the journey canvas, click the edit icon in the top-left corner. The same settings panel opens.
2
Update the concurrent entry setting
Change Allow concurrent entry? to Yes or No as needed.
3
Click Publish Workflow
A confirmation popup appears asking how to handle returning users.
4
Review the publish popup
If concurrent entry is enabled, an amber information box appears in the popup confirming it is on and summarising its behaviour. Review and confirm.
Publish this Workflow popup showing the amber 'Concurrent entry is enabled' callout.
5
Select how to handle returning users
Choose Remember users (existing journey state is preserved) or Reset users (journey state is cleared and users may be re-evaluated). Then publish.
Concurrent entry is enabledWith this on, the same user can run through this journey more than once at the same time. Each new trigger starts a fresh, independent instance for that user.For most journeys — onboarding, re-engagement, suppression — keep this off. This can result in duplicate communications or break suppression logic.
The journey will not publish until you explicitly confirm. This ensures the setting is always a deliberate choice.
Concurrent entry and re-entry are related but separate settings.
Setting
What it controls
Allow user to re-enter the journey?
Whether a user who has already exited the journey can enter it again. Controlled by a time window after exit. See Add Re-entry Criteria.
Allow concurrent entry?
Whether a user who is currently active in the journey can also start a new instance simultaneously.
Concurrent entry only appears as an option when re-entry is set to Yes. However, they control different things — re-entry is about users returning after they have left; concurrent entry is about users having multiple active instances at the same time.
If re-entry is off, concurrent entry is not available. Turn re-entry on first to access the concurrent entry option.
What happens to active instances if I turn concurrent entry off on a live journey?
Active instances are not interrupted. They complete normally. Only new triggers are affected — they will queue as standard (one at a time) once concurrent entry is turned off.
Is there a limit to how many concurrent instances one user can have?
There is no hard cap. Each qualifying trigger creates a new instance. Design your journey with your expected trigger frequency in mind.
Will suppression logic still work with concurrent entry on?
Suppression actions apply per instance. If a user has multiple concurrent instances, one may trigger suppression while others are still progressing through earlier nodes. For journeys where suppression is critical, keep concurrent entry off.
Does concurrent entry affect journey analytics?
Yes. Journey analytics count instances, not unique users. With concurrent entry on, a single user contributing multiple instances will be counted multiple times in node-level metrics.
I'm not sure if my use case needs this. Who can help?
Reach out to your Customer Success Manager. They can review your journey design and advise on whether concurrent entry is the right approach.
