Currently, there is no native option to start a scenario at the exact moment a customer enters a segment, as segment entry doesn't generate an event that can be triggered. This article describes practical workarounds you can use instead.
Workaround 1: Recurring or event-based check
Use this approach if you don't need to remember the previous segment, and it is enough to say:
"If the customer is currently in segment X, run action Y."
In this case, you can use a single-flow scenario that checks if the customer is in the target segment(s) at regular intervals or at the moment of a specific event.
Option A: Recurring trigger
Use a recurring trigger (On date / Repeat)
-
After the trigger, check whether the customer belongs to the desired segment using a condition node.
Optionally, you can use a segmentation fork instead of the condition node.
-
Prevent repeated sends. Use, for example, the "hasn't received the campaign yet" condition in the scenario, or configure the Frequency policy.
This condition ensures that
Customers don't re-enter the scenario.
Duplicate emails or messages aren't sent to the same customer.
-
Only newly qualified customers in the segment receive the communication.
-
If the condition is true, run the desired action (email, SMS, mobile push, webhook, and more).
Example scenario setup
The goal is to target customers who have been newly added to a specific segment.
The scenario starts with a repeating daily trigger.
This is followed by a segmentation node that evaluates whether the customer belongs to the desired segment.
Next, a condition node is used to exclude customers who have already received the campaign within a defined timeframe (for example, the last 60 days or lifetime).
You can add additional filters, such as confirming that the customer has granted email consent.
The scenario ends with an email node.
Limitations
While this workaround works, it isn't truly event-driven; it depends on scheduled checks and a retrospective time window. This can lead to duplicate sends and missed opportunities, especially if the timing of customer segment entry doesn't align with the scenario’s schedule or the condition node’s time window.
Option B: On event trigger: use events from the segmentation logic
Using the same logic as above, if the segmentation is based on specific events (for example, "last order"), you can use an On event trigger on the relevant event (for example, order event).
Note: Some event statuses and certain system events don't trigger scenarios; always verify that the event type and status you want to use are supported as scenario triggers in your project. Read about the trigger limitations in this documentation.
Workaround 2: Two-flows scenario: tracking previous and current segment
Use this approach if you want to store and later display (for example, in an email content) the previous segment from which the customer came.
You will create two separate flows:
- Flow 1: Tracks and stores the customer’s current segment.
- Flow 2: Detects a change of segment and executes the desired action.
First flow: tracking current segment
- Use a Repeat trigger to run daily (or at another suitable frequency).
-
Filter customers with a condition node who belong to the chosen segmentation.
-
Determine the customer's current segment and store it in a custom customer attribute, such as
last_segment_name,using a Set attribute node. -
Each run updates
last_segment_name, so it always reflects the most recent segment value at the time the flow executes.
Second flow: detecting a segment change and executing an action
- Use a Repeat trigger to run daily (or at another suitable frequency); however, keep in mind that this flow needs to run at a different time than the first time to give customers time to move between the segments.
Right after the trigger, add additional conditions to limit the audience (customers who belong to the relevant segmentation/customers with required attributes or consent).
-
Prevent repeated sends. Use, for example, the "hasn't received the campaign yet" condition in the scenario, or configure the Frequency policy.
-
Add a condition node that compares the current segmentation attribute to
last_segment_name. If the current segment doesn't equallast_segment_name, the customer has moved to a different segment since the last run. For customers where a change is detected, add another Condition (or Segmentation fork) to check whether the current segment is one of the segments you care about. Only customers whose current segmentation value matches the target segment(s) will continue.
Place your action(s) for matching customers, such as email / SMS / push action nodes, and more.
-
Until the first flow runs again, the previous segment will remain stored in the
last_segment_nameattribute, so you can use this value in the email or message content or any other follow-up logic that needs to know the previous segment.