Wait activity wait-activity
The Wait activity adds a delay in a journey before executing the next activity. This feature ensures proper timing and sequencing, enabling more personalized experiences. For example, delay sending a follow-up email after a purchase or pause before initiating the next step based on customer behavior. The maximum wait duration is 90 days.
Configure two types of Wait activities:
- A wait based on a relative duration. Learn more.
- A custom date, calculated using advanced expressions. Learn more.
Recommendations wait-recommendations
Multiple wait activities multiple-wait-activities
When using multiple Wait activities in a journey, consider the global timeout, which is 91 days. This ensures profiles exit the journey no later than 91 days after entering, regardless of their progress.
For example, if a Wait activity is configured for 30 days but the profile enters it with only 25 days remaining in the journey, the profile exits before completing the wait. This maintains consistent and predictable journey timing. Learn more on this page.
Wait and reentrance wait-reentrance
Avoid using Wait activities to manage reentrance. Configure reentrance behavior at the journey properties level using the Allow reentrance option. This prevents bottlenecks and ensures smoother execution. Learn more on this page.
Wait and test mode wait-test-mode
In test mode, use the Wait time in test parameter to shorten wait durations to 10 seconds. This allows you to simulate journey execution quickly and verify behavior without delays. For example, observe how profiles progress through multiple Wait activities in minutes instead of days. Learn more on this page.
Wait and mobile channels wait-mobile-channels
When working with mobile channels like in-app messages and push notifications, use Wait activities to synchronize timing between interactions. For instance, send a push notification and introduce a 5鈥15 minute wait to ensure the in-app message payload propagates before displaying. This ensures seamless customer experiences and effective personalization.
Configuration wait-configuration
Duration wait duration
Select the Duration type to specify the relative duration of the wait before executing the next activity. The maximum duration is 90 days.
For example, to wait 7 days after sending an email, configure the Duration wait for 7 days. This ensures the next activity begins only after the specified time has elapsed.
Custom wait custom
Select the Custom type to define a specific date for the next activity using advanced expressions based on data fields. This option provides flexibility for tailoring wait times to individual profiles or events. Instead of setting a fixed duration like 鈥7 days鈥, dynamically calculate a date, such as 鈥2 days after a purchase鈥.
For example, use an expression like toDateTimeOnly(@event{Event.productDeliveryDate})
to trigger the next activity based on a product delivery date. This ensures timing aligns with customer-specific data. Avoid fixed dates like toDateTimeOnly('2024-01-01T01:11:00Z')
, as they may cause execution issues across profiles.
The expression editor should output a dateTimeOnly
format. Refer to this page for details. For more information on the dateTimeOnly
format, see this page.
Dynamically calculate dates to personalize journeys rather than applying static dates. This approach enhances relevance and avoids potential conflicts.
dateTimeOnly
expression or a function to convert data to dateTimeOnly
. For example: toDateTimeOnly(@event{Event.offerOpened.activity.endTime})
, where the event field contains a timestamp like 2023-08-12T09:46:06Z
.2023-08-12T09:46:06.982-05
. Learn more about time zone handling here.To verify that your Wait activity functions correctly, use step events during testing. Learn more.
Automatic wait node auto-wait-node
Inbound message activities (for example, In-app message, Code-based experience, or Card) automatically include a Wait activity set to 3 days. This ensures profiles engaging with these messages have sufficient time to act before the journey progresses.
For example, if an in-app message is sent, the 3-day wait ensures the message remains visible long enough for users to take action. Remove or customize this default Wait activity to meet your journey鈥檚 requirements.