Sometimes you just need to wait. You probably don’t want all your messages in your journey to be sent all at once. By adding wait events you can wait a specific number of days for the next message in your journey to be sent.
Waits will be automatically suggested when adding a step, you then need to confirm the wait or delete it.
This article covers:
Select the number of days the contacts in the Journey should be set on hold until the next step of your Journey should be executed.
You can also select minute waits which will run independently of the selected journey frequency.
Please note that minute waits are designed to handle smaller amounts of contacts, for example individually triggered after a purchase. Bigger batches of contacts entering the wait may cause a longer waiting period than stated.
For Tailored Journeys you can add waits based on hours.
If you have selected to run an hourly Journey you'll select the number of hours.
Note that we only recommend minutes when using the Event Hub and you're in the process of updating a contact.
Tailored Journeys is an add-on feature. Reach out to your success manager at Symplify to learn more.
Wait for API call
When you want to manage the waiting time based on events in other systems you can use the Wait for API call.
You can then push a contact forward in your flow whenever connected events are completed. View an example below.
This wait will always provide three paths: accepted, rejected and timeout.
In order to get this wait up and running you must set up a webhook endpoint. These are managed on Account settings. Under journey settings you can also choose to set a unique endpoint for a specific journey (this will override the account/project settings).
The endpoint must manage the incomming hooks asynchroniously.
For each contact entering the wait step, a webhook will be triggered to the endpoint. The webhook contains unique information about how to release each contact from the wait.
And you've actually got two release options, to accept further advancement in the main flow or to reject. Each contact gets a unique accept request and a unique reject request.
To ensure that no contacts get locked in a waiting limbo you need to add a maximum waiting time which will release the contact to a timeout path if no accept or reject request has been triggered.
The webhook endpoint is managed on Account settings > (Integrations) Journey Wait configuration. Beside your endpoint, you can also add an optional header and authentication if needed.
In the actual wait step you'll add a webhook identifier to specify the step.
You can also add optional custom fields to include in the webhook. These will be included in the webhook to help you identify the wait.
Wait until date
With this wait, contacts will wait until a given:
day of the week = wait until it's Monday
day of any month = wait until the third of April/May/June/etc. (each year)
day of a specific month = wait unil the third of April (each year)
specific date and year = wait until the third of April 2020.
For each option, except specific date and year, you can add multiple days. This means that you can for example release contacts from the wait on both Mondays and Thursdays.
Please note that if the selected specific date and year (the last one) has passed, contacts will not wait but go immediately to the next step in the journey.
Wait for segment match
This wait enables you to run contacts through a segment but hold those who doesn't match in the wait for a new try at a later point.
When your contacts reach this wait they will be tested for your added segment. Matching contacts will continue on path A. If they don't match, they will stay in the wait and repeatedly be checked against the segment (on your given journey frequency).
If they haven't matched the segment before the timeout you've selected is reached, they will follow path B.
Use an already created segment or build a new one. Then set the maximum time for retry.
Note that you may want a regular wait (days/hours) before this wait.
In order to limit the amount of messages to be sent to a contact from different Journeys, you can add a Priority wait.
If a contact is about to receive messages from different Journeys on the same day, this wait will cancel the following message from the Journey(s) you consider to be lower prioritized.
Each Priority wait must be connected to a rollup. When contacts reach the wait, via Priority waits in different Journeys, the rollup gathers and holds them until your given run time. The contacts will then get evaluated for further advancement in your journeys.
So, first you need create a rollup. Go to Account settings > Priority rollup (only admin users can manage rollups).
Click on Create a schedule where you name your rollup and set the time.
Note that your journeys will be processed at your given frequency but contacts reaching a Priority wait will stay there until the time of your rollup (daily).
Back on Journeys, locate the journeys you want prioritize and go to Settings.
Under Advanced settings you can a number between 1-100 (where 1 is your highest ranked journey).
If you have more than one journey with the same priority, these will be considered as equal (if the waits are connected to the same rollup).
Note that only journeys connected to same rollup will get matched to each other. Example, if Journey A (prio 1) and Journey B (prio 2) are connected to rollup 1, you can still add Journey C with prio 1 connected to rollup 2, without interfering with journeys A or B.
Edit the wait
On the editing workspace, add a Priority wait before a message step you want to prioritize, and go to Edit.
Select the rollup you want to connect to your wait.
If you want denied contacts to get another run the following, simply toggle Automatic retry. By doing so, path B will not be editable.
Note that message steps without a Priority wait in front will be sent as normal (even if you've added a priority on the journey itself).
This is an add-on feature. Reach out to your success manager at Symplify to learn more.
Wait for API call example
You're setting up a Journey for new orders. First you have an API starter that triggers an order confirmation. The contact continues to the Wait for API call (since you want to wait until the order has been shipped before you send the shipping confirmation).
A webhook is triggered to your endpoint with the contact unique information. When the order is packed and shipped you trigger the accept request you received in the webhook and the contact will be released and continue your main flow and receive the shipping information.
But, if shipping is delayed you can trigger the reject request and then the contact will be released to the reject path, where you can send information about the delay.
The third path, time out, is to release contacts that has not been either accepted or rejected within the expected timeframe.