Experiences in the Experience Engine run on triggers. A Starting Condition starts an Experience for a student, and a Stopping Condition ends it. In this article we'll look at how to use Stop Triggers.
One of the most common questions we get is why an Experience still sent an email or SMS after the date you expected it to stop. In almost every case this comes down to how Stopping Conditions actually work, and it is expected behavior rather than a bug.
Stopping Conditions are events, not retroactive filters
For a Stopping Condition to end an Experience for a student, the stop event needs to happen after the student has entered the experience.
It works in real time and going forward. It watches for the stop event to occur, and at that moment it halts the sequence for that student.
It does not look backward. If the stop event already happened before the student entered the Experience, then there is nothing for the Stopping Condition to catch, and the Experience keeps running.
The most common case: a student added after the stop date
This is usually what is happening when an Experience seems to run past its stop date.
Say you set a Stopping Condition tied to a specific date, and that date has already passed.
If a student is then added to the course, or enters the Experience, after that date, the stop event is already in the past for them.
It never fires while they are active, so the Experience runs for them as if no stop had been set.
A related behavior: changing a trigger after it has fired
If you change a trigger after it has already fired for a student, it will not change the Experience for that student. It only changes the Experience for new students going forward. So editing a Starting or Stopping Condition does not retroactively rewrite what is already in motion for students who are already in the sequence.
How to reliably stop an Experience for the right students
Because Stopping Conditions are real-time events, the way to control who receives an Experience is to set conditions the right students will actually meet while active, rather than relying on a stop date or event that may already be in the past. A few reliable options:
Use a Stopping Condition the student will actually trigger while active. For example, setting "Student logs in" as the Stopping Condition ends a Student Rescue Experience the moment the student logs back in.
Use the "And Only For Students Who Joined Course" window so the Experience only targets students who joined within a timeframe you choose.
Set the run frequency deliberately. Be careful with "As Often as Triggered," which can cause an Experience to run more often than you expect.
To include or exclude a specific group, gate the Experience with tags. Tag the students who should receive it, start the Experience on that tag, and remove the tag to take a student out of it.
Key takeaways
Starting Conditions start an Experience, and Stopping Conditions end it.
A Stopping Condition only stops the Experience if its event happens while the student is active in the Experience.
It is not retroactive. A student added after a stop date has already passed will still receive the Experience.
To control who receives an Experience, use Starting Conditions, the joined-course window, run frequency, or tags, rather than a stop date that is already in the past.
Related articles