Run Later
The Run Later block is used to schedule a set of flow stages to be run at a later time.
This stage has an additional output (the purple circle) which is the path that is followed once the timer has elapsed. Immediately on Flows execution the green path will be followed but the block will wait for the amount of time indicated and then run the purple path.
Field | Description |
Timer ID | A unique identifier for the timer. This ID can be used in other parts of the flow to reference the timer and stop it or get the time till next run. It can also be used in other Flows if using the same timer ID |
Delay Time (mins) | How many minutes to wait before running the scheduled flow path. Use the @ filter to find helpful timer function such as "In 1 day". |
Restart Timer | Used to indicate what action should be taken if this stage is called multiple times per Timer ID. If set to "True", the timer will always be reset if the stage is called multiple times so that the scheduled flow path is only ever run ONCE per Timer ID. |
Use caution when calling this stage multiple times and setting the Restart Timer flag to False as this will create multiple running timers per flow trigger in parallel
You can use the following helpers in the Delay Time:
@Now
@NowSecond
@End_of_Day
@24_hours
@1_hour
@5_mins
@Next_Monday_6am
@Start_next_Month
@5_days
@7_days
@14_days
@21_days
@Forever
You can also add a mathematical function directly in the field to get the minutes, such as "=60*24*6" to get 6 days in minutes (60 minutes times 24 hours times 6 days).
Example:
1. Trigger an action X minutes (the delay) after deposit when no further deposit has been made.
Trigger: On succesful deposit
Run Later Stage: Set the Delay time to the time you want between the last succesful deposit and the action.
Restart timer: Should be set to Yes for this use case. For example, if it is set on Deposit it will reset every time the user deposits, hence not triggering the following action.
If you want the timer to be per User - then add the UserID in the timer name, for example "nodepositXmin_{{userID}}"
Action stage: After the purple path, for example "add bonus" or "send to Slack" to alert the VIP team (if you first filter on VIP tags) on no deposits in X time.
2. Set an alert if no Login has come through for the user during X days (the delay).
Trigger: On login
Run Later Stage: Set the Delay time to the time you want your alert to trigger on. For example set it to 5 days in minutes (=60*24*5) if you want an alert on no logins during the last 5 days.
Restart timer: Should be set to Yes for this use case. The timer will then reset on every login and only run the purple path if the time between the last login and now exceeds the delay time.
If you want the timer to be per User - then add the UserID in the timer name, for example "nologinXdays_{{userID}}"
Action stage: After the purple path, in this example you can add a check if VIP and then alert the VIP team that this particular VIP has not logged in for 5 days. You can also add actions such as updating segment and triggering anti-churn campaigns.
How Run Later works when enabling a new version of a flow
When you enable a new version of a flow, existing Run Later stages behave differently depending on whether the target stage still exists and remains connected. Here’s what happens in different scenarios:
Scenario 1: No changes to the scheduled stage
- Before: The Run Later stage is set to execute Stage 10 (connected to the blue dot).
- After: A new version is enabled, but Stage 10 remains connected.
- Result: The Run Later stage fires as expected when the delay time elapses, including for triggers that came through and reached the Run Later stage before the last version was enabled. Any changes made to stage 10 will also be executed for those that were in previous versions.
Scenario 2: The scheduled stage is deleted
- Before: The Run Later stage was set to execute Stage 10.
- After: A new version is enabled, but Stage 10 is deleted and replaced by Stage 11.
- Result: Any Run Later events scheduled in the previous version will not fire since Stage 10 no longer exists.
Scenario 3: The scheduled stage is disconnected but not deleted
- Before: The Run Later stage was set to execute Stage 10.
- After: A new version is enabled, and Stage 10 is disconnected from the blue dot but still exists.
- Result: The Run Later event still fires, as Stage 10 is still part of the flow, even if it’s no longer on the main execution path.
Key takeaways
When a Run Later event is scheduled, the system saves the exact stage it’s meant to run. Once the delay time elapses, it tries to execute that specific stage:
✅ If the stage exists (even if disconnected), the event fires.
❌ If the stage is deleted, the event does not fire.
How to stop a Run Later event from firing
If you need to prevent scheduled Run Later events from executing in a new version, you have two options:
- Stop the flow – This cancels all scheduled timers and prevents pending Run Later events.
- Delete (not just disconnect) the blue dot stage – If the stage is fully deleted before enabling the new version, any scheduled Run Later events referencing it will not fire.
This prevents unwanted executions from affecting your updated flow.