Making sure that users exit a journey when you expect them to is almost as important as ensuring that they enter it when they're supposed to. After all, you don't want to keep sending messages to users after the content is no longer relevant to them!
This article tells you everything you need to know about setting up exit paths for users in your journeys.
# In this article
# Filtering users out of a journey at a specific point
You can use filter tiles to remove users at different stages of the journey. Let's consider a couple of examples.
# Removing users who don't have a specific attribute
Let's say you want to remove users from a journey who don't match the conditions of an Attribute split tile. To do this, leave the Everyone else branch unconnected Users who don't match any of the criteria you've set up will be sent down this path and be removed from the journey.
Alternatively, you can uncheck the Add an "Everyone else" branch when you're setting up the Attribute Split tile—users who don't match the criteria you've set up will be removed from the journey.
If you want to remove users at a specific point in the journey, use a filter tile.
# Removing users who don't engage with a message
Let's say you want to remove users who aren't engaging with a promo sequence. You could add a Yes/No Split tile that checks for an open or click after a message tile. If you want to remove users who haven't opened or clicked the message, leave the "No" branch unconnected.
# Removing users for a specific action or attribute
If you want to remove users when a certain event occurs — no matter where they are in the journey — use an exit rule. Removing a user from a promo sequence as soon as they make a purchase is a good example.
Review these points to understand how exit rules work:
Users who meet the criteria for an exit rule are removed from a journey when they finish the tile they're on.
Users in a Time Delay tile are an exception to the previous behavior — they are removed from the journey within 48 hours of the occurrence of the event or user profile update, or before moving to the next tile (whichever comes first).
Exit rules apply to an entire journey, not just a specific step. Wherever a user is in a journey, they stop receiving messages as soon as they meet an exit rule's criteria.
You can set up as many exit rules as you like. Users only need to match the criteria for one of your exit rules to be removed from a journey.
If a user satisfies exit criteria in a journey that has STO enabled, the message will still be sent at the optimized time chosen by STO, even though the user exited the journey.
# Creating exit rules
To add exit rules to a journey, click Exit rules in the lower left of Studio.
As you're setting up your exit rules, think about whether you want users to be removed from the journey when they meet a single condition or a group of conditions:
To remove users when they have met multiple criteria, add a single exit rule with multiple conditions. Use the + Condition button to add each additional condition to the exit rule.
To remove users who meet at least one of many separate conditions (or groups of conditions), add multiple exit rules to the journey. Use the + Add rule button to add each additional rule.
# Configuring exit rules based on changing list membership
When configuring an exit rule to remove users from the journey when their list
membership changes, it's important to consider your use case requirements and
how the different options for exit rule criteria work. It's possible to create
exit rules that check for updated list membership using either the Property Changes
or Event Occurs option, and the results of these two options are
fundamentally different. In general, use Property Changes when list
membership is updated by changing a user's emailListIds or userListIds
field through user update API calls, and use Event Occurs when list
membership changes need to be detected through subscribe or unsubscribe events.
Before setting up an exit rule that removes users from a journey when they're
subscribed to or unsubscribed from one of your lists, consider how you plan to
trigger those changes and choose the right option for your use case
accordingly.
# Property Changes
The Property Changes option is triggered only when the user's
emailListIds
(for email-based projects) or userListIds
(for userID-based and hybrid projects) user profile field is updated through a
call to the following API endpoints:
- Update a single user:
POST /api/users/update - Bulk update users:
POST /api/users/bulkUpdate
These endpoints update the user's profile fields directly rather than generating subscribe or unsubscribe events.
An exit rule configured with the Property Changes option isn't triggered when a user's list membership is updated through:
- Calls to the following Iterable API endpoints:
- Bulk update subscriptions for a list of users:
PATCH /api/subscriptions/{subscriptionGroup}/{subscriptionGroupId}/user/{userEmail} - Update subscriptions for a user (by
userId):PATCH /api/subscriptions/{subscriptionGroup}/{subscriptionGroupId}/byUserId/{userId} - Update subscriptions for a user:
POST /api/users/updateSubscriptions
- Bulk update subscriptions for a list of users:
- CSV uploads that update user profile fields
# Event Occurs
If you want users to exit a journey when they're added to a particular list, configure an exit rule with Event Occurs > Subscribe > User List for that list. If you want users to exit when they're removed from a list, use the corresponding unsubscribe event condition for that list.
An exit rule configured with the Event Occurs option (such as Subscribe > User List) can be triggered when the user's list membership status is updated through methods such as:
- Calls to the following Iterable API endpoints:
- Bulk update subscriptions for a list of users:
PATCH /api/subscriptions/{subscriptionGroup}/{subscriptionGroupId}/user/{userEmail} - Update subscriptions for a single user (by
userId):PATCH /api/subscriptions/{subscriptionGroup}/{subscriptionGroupId}/byUserId/{userId} - Update subscriptions for a single user:
POST /api/users/updateSubscriptions - Subscribe users to a list:
POST /api/lists/subscribe - Unsubscribe users from a list:
POST /api/lists/unsubscribe
- Bulk update subscriptions for a list of users:
- CSV uploads that update user profile fields
# Users who unsubscribe
Let's say you want users to exit a journey if they unsubscribe from
your newsletter. You could set up an exit rule that checks your Newsletter Subscribers
list for an Unsubscribe event and removes a user from the journey when one is found.
# Additional uses for exit rules
Some other possible uses related to exit rules include:
Removing a user from a journey immediately after they complete a specific action, by using journey conversions as exit criteria. After they're removed, you can send them to a different journey, if you want to.
Excluding users from a journey who have a certain user profile attribute (and may have been removed from the journey previously via exit rules), by setting up entry rules in the Start tile to filter them out.
NOTE
Handlebars expressions are not supported in exit rules.
# Journey exit events
When a user exits a journey, you can set up your journey to track a journeyExit
event.
To learn more about journey event tracking, see Monitoring Journey Engagement.
# Reasons for journey exits
When a journey exit event is logged, the event includes an exitReason field
that contains the reason for the user's exit.
# Expected exit reasons
Expected exit reasons occur when the journey is working as designed. No action is required.
| Exit Reason | Description |
|---|---|
CampaignSelectorGoalAchieved | The user met the goal condition configured in the journey. |
CampaignSelectorNoMoreTemplates | The journey had no remaining campaigns or templates to send to the user. |
Completed | The user completed the journey as expected. |
ExitRulesMatched | The user satisfied one or more of a journey's configured exit rules. |
InAnotherJourney | The user is excluded by concurrent-journey entrance criteria. |
NoTriggerMatch | The user did not meet the entry conditions for their triggering event or profile data. |
UserIsDeleted | The user's profile was deleted from Iterable, and they were removed from the journey. Iterable normally does not log a journeyExit event because the profile no longer exists. When no event is logged, the exit does not count toward your Journey Events limit. |
UserIsForgotten | The user was forgotten through a GDPR request, and they were removed from the journey. Iterable normally does not log a journeyExit event because the profile no longer exists. When no event is logged, the exit does not count toward your Journey Events limit. |
WorkflowDisabled | The journey is disabled. |
# Unexpected exit reasons
Unexpected exit reasons may indicate a problem with your journey setup or related integrations. Any reason code that isn't listed above may be considered unexpected. This list is subject to change.
Due to the complexity of journey troubleshooting, these reason codes don't have detailed descriptions but are here for reference. Investigate these when they appear, and contact Iterable support if you need help.
CallWebhookExceptionCampaignNotFoundCustomEventFromUserUpdateNotAllowedDraftNodeDataInvalidGenericSendActionCampaignContextNotFoundGenericSendActionMessageMediumNotFoundGenericSendActionTemplateNotFoundInvalidDateInputInvalidEmailHeaderInvalidHandlebarInvalidJsonInvalidQueryInvalidWebhookUrlMessageChannelNotFoundMessageTypeNotFoundNoABSplitFoundNoFieldSplitMatchNotEnoughMessageMediumsConfiguredProjectNotFoundRetryLimitExceededUnknownExitReasonUserUpdateFieldLimitExceededUserUpdateFieldTypeMismatchUserUpdateFieldsAreForbiddenUserUpdateFieldsUnprocessableWebhookBodyIsNotJsonWebhookBodyIsNotJsonObjectWebhookPermanentFailureWebhookSSLErrorWorkflowNotFoundWorkflowStepNotFound
# Triggering journey exits with list and subscription imports
If you want a list or subscription import to remove users from a journey, enable the Trigger journey entries and exits with this import option while setting up the import.
With this setting enabled, list imports can remove users from journeys when linked exit rules using Subscribe to User List conditions are met, and when Property Changes conditions for supported user profile fields are met. Property Changes > List Membership isn't triggered by list imports. To learn more, see Configuring exit rules based on changing list membership. Subscription imports can remove users when linked subscribe or unsubscribe message channel exit rule conditions are met. The same setting also controls whether those imports can add users to journeys through related entry sources.
To learn more about this setting, see Adding Users and Creating Lists. For guidance on when to use a list-based entry source instead of a schedule, see Choosing between Schedule and Subscribe to List.
# Troubleshooting journey exits
Ideally, users will only exit a journey when they've satisfied the criteria you've set up. But sometimes, an unexpected condition triggers a user's exit from a journey. If a user exits a journey unexpectedly, consider whether any of the following circumstances exist.
# Unconnected tiles
Any tile that isn't connected to another tile in a journey is an exit point. Keep this in mind as you build a journey. You can intentionally leave a tile unconnected if you want users to exit the journey after they finish that tile. But remember not to leave a tile unconnected if you want users to continue beyond that step in the journey!
If you want users who reach the end of a path in one of your journeys to be added to another sequence, add a Send to journey tile to the end of the path.
# Failed webhook calls
If a webhook call fails for one of your users, the user will exit the journey. Keep this in mind as you set up any Call webhook and User profile tiles you've added to your journey.
See Journey Webhooks to learn more.
# Deleting tiles
When you delete tiles from a live journey, any users who are in those tiles at the time you publish your changes are removed from the journey. This is true for all tile types—however, users in deleted Time Delay tiles must complete the delay period before they exit the journey. To learn more, see Deleting Tiles.
# Null fields and journey exits
In some cases, null values for boolean fields may prevent users from exiting a journey. If you update fields (for example, in a user profile) and null values are added, consider the potential impact to journey exits.
# Turning a journey off
When you turn a journey off, users who are in the journey will be removed after they complete the step they're on. However, if the journey is turned back on while a user is still in a Time Delay tile, the user is not removed from the journey when they reach the end of their delay — they proceed to the next tile.
If you don't want to remove any users from the journey, but you want to prevent new users from entering it, disconnect the Start tile.
# Want to learn more?
For more information about some of the topics in this article, check out this Iterable Academy course. Iterable Academy is open to everyone — you don't need to be an Iterable customer!
Iterable Academy:
Support docs: