Wait types
You can configure the Wait block in three ways:- Fixed — wait a set number of minutes, hours, or days.
- Dynamic — wait until a date stored in a field on the customer or another entity.
- Time interval — don’t wait, but only let customers exit during specific hours or days of the week.
Fixed
Set the number of minutes, hours, or days to wait. You can also restrict the hours and days of the week when customers are allowed to exit the block. Example: Wait 7 days after delivery, then between 10:00 and 20:00 ask the customer to review the order.Time interval
No waiting period is applied, but the customer can only exit the block during the hours or days of the week you specify. Example: Hold an abandoned cart message so it isn’t sent overnight.Dynamic
Dynamic Wait uses a value from a custom field on the customer or another available entity with a Date or Date and time data type.Fields with the Date type don’t include a time, so they default to midnight.
- The moment the time in the field arrives.
- N minutes, hours, or days before that time.
- N minutes, hours, or days after that time.
Which dates are available in which events
Every flow can use a Wait based on a customer field. The events that trigger a flow also carry their own data — for example, custom fields on the order or product. Selecting an event lets you configure the Wait against custom fields on the entities passed in by that event, through dedicated contexts. The table below lists the available contexts and the events where each one can be used.| Context | Events where available |
|---|---|
| Customer field | All flows |
| Order field | New Order; Order Data Changed; Order Status Changed |
| Action field | New Order; Order Data Changed; Order Status Changed; Viewed Product Changed; Action Performed; Product-Related Action Performed; Customer Changed Email; Customer Changed Mobile Phone; Customer Balance Became Negative; Bonus Points Became Available; Set Balance Changed; Discount Card Status Changed; Discount Card Replaced |
| Product field | Product in Order Delivered; Product in Order Paid; Product in Product List Changed; Product List Changed; Viewed Product Changed; Preferred Product Changed; Product-Related Action Performed |
| Line item (position) field | Product in Order Delivered; Product in Order Paid |
| Product expiration date | Product in Order Delivered; Product in Order Paid; Product in Product List Changed; Product List Changed; Viewed Product Changed; Preferred Product Changed; Product-Related Action Performed |
| Points expiration | Customer Balance Became Negative; Bonus Points Became Available; Set Balance Changed |
| Discount card information field | Discount Card Status Changed |
| Operation variable | Operation Called |
Examples of dynamic Wait
Triggering before a date
Goal: Remind a customer that a webinar is about to start. Solution: Store webinars as products and pass the start date and time in a custom field. Start the flow off the registration using the Product-Related Action Performed event with the right template. Set the Wait against the product data. Other use cases:- Remind a customer about an upcoming class or lecture.
- “A product from your order is running low” flow.
- “Your points are about to expire” flow.
Triggering on a date
Goal: Remind a customer to pick up a pickup order on its last day of storage. Solution: Pass the order’s storage end date as a custom field. After delivery and the initial message, if the customer still hasn’t picked up the package, send a reminder on the last day.Triggering after a date
Goal: Ask a customer for a review after a tour. Solution: Pass the return date from the tour as a custom field on the order. After payment, wait 3 days from the return date, then request feedback. Other use cases:- Post-trip survey flow.
How Wait affects flow progression
The current “time of progression” for a flow is set by these blocks:- Event — uses the time of the event itself, not when it reached the project.
- Schedule — uses the scheduled time.
- Step group — running the steps sets the current date and time of progression.
- Wait — moves the date and time of progression forward by the configured interval.
Relevance period
Relevance is the window during which it still makes sense to run the steps. It’s measured from when the customer entered the flow (the event or schedule block) or from the exit of the previous step group. Fixed and dynamic Wait pause progression. An hour restriction only postpones execution of the block — progression, and the relevance countdown along with it, resumes. Example: In a welcome series, the second email runs with a time restriction, and step group relevance is 1 day. A customer signs up on August 1 at 22:00 and immediately receives the first email. The next one goes out on the morning of August 5:- Progression is paused from August 1 22:01 until August 4 22:01.
- Execution of the next block is postponed until morning, but progression and the relevance countdown resume at 22:01.
- Before the step group runs, the system checks whether more time has elapsed since the previous step than the configured relevance — 12 hours have passed (August 4 22:01 to August 5 10:01), which is within the 1-day window, so the email is sent.
Filters with floating dates
For filters with floating dates (“current day”, “up to 2 hours ago”, and so on), the moment the filter is built matters. Fixed and dynamic Wait move progression — and the time the filter is applied — forward by the configured interval. An hour restriction postpones execution of the next block, but the time context (including for filters) stays at the moment progression resumed. Example: A customer enters a flow on August 6 at 23:00. A fixed Wait pauses progression from August 6 23:00 to August 13 23:00. Progression then resumes, and filters use that moment as the reference point — even if execution of the next block is postponed to the allowed hours (until August 14 10:00). How this affects different filter types:- Calendar filters (“calendar day/week/month/year”, “anniversary”) treat the time progression resumed as the current day — August 13. The check verifies there were no orders on August 13, even though it’s already August 14.
- Interval filters from a date (“date and time will occur / has occurred”) count from the moment progression resumed — from August 13 23:00. The check verifies there were no orders between August 12 23:00 and August 13 23:00.
- Interval filters from the current time (“period from the current date”) count backward from the moment progression resumed — from August 13 23:00. The check verifies there were no orders between August 12 23:00 and August 13 23:00.
- If you don’t constrain by the nearest time boundary, the window extends to the moment the filter is actually applied: the check verifies there were no orders between August 12 23:00 and August 14 10:00.