Use Journey actions to control how and when users move through your Journey, personalize experiences, and test outcomes.

​
Wait

Delay the user’s Journey progression by a specific amount of time—minutes, hours, days, or weeks. Use it to:
  • Space out messages and steps
  • Allow time for users to engage with a message before branching

A wait node with users currently waiting to progress in the journey

​
Wait until

Hold a user at this step until they meet specific conditions:
  • Entering a segment
  • Triggering a message event (e.g., specific message delivered, opened, or clicked)
    • Only one message event per wait until step is supported at this time.
  • Triggering a custom event (e.g., onboarding complete, purchase made) - BETA
You can add multiple conditions and branch users based on the first condition they meet. If those conditions are not met in a certain amount of time, you can set an expiration branch to continue users through the Journey or exit them completely. Using the Custom Events entry rule (BETA), you can also add Event Matching to control which instance of the user to progress through the Journey if you enter them multiple times.

Wait Until user is in a segment or triggers a custom event

When a custom cvent matches a condition, that event is stored on behalf of the user and may be referenced in Liquid syntax when sending Journey messages.

​
Event Matching

Wait Until Action with Custom Events is currently in beta. To request access, contact support@onesignal.com with:
  • Your company name
  • Your OneSignal Organization ID
  • The OneSignal App ID(s) where you’d like access
Using the Custom Events entry rule, you can have users enter a Journey multiple times. With the Wait Until step’s Event Matching setting, you can control which instance of the user to progress through the Journey. Requirements:
  • Set the Journey Entry Rules to use a custom event.
  • Include an event property when entering users into the Journey.
For example, you have a “Survey Reminder” Journey. You have multiple surveys which means users can enter the Journey multiple times (once for each survey). You want to send a reminder message if they did not complete the survey or remove them if they did. You can use the Event Matching setting to control which instance of the user to progress through the Journey. Example:
1

Set the Journey Entry Rules and custom event properties

Set the Journey Entry Rules to use a custom event. Example: survey_start

Journey Entry Rules using a custom event

Users will enter the Journey via the Custom Event API.The custom event will have the name set to survey_start and a payload property survey_id with a value of the survey they are taking (e.g., survey_1).
Entrance Trigger Event Example
{
  "events": [
    {
      "external_id": "UserA",
      "name": "survey_start",
      "payload": {
          "survey_id": "survey_1"
      }
    }
  ]
}
2

Create a Wait Until step and custom event properties

Set the Wait Until condition to use a custom event. Example: survey_completeSet the Event Matching option to specify which instance of the user to progress through the Wait Until step by matching the:
  • Trigger Event Property: set in the Journey entrance trigger event (e.g., survey_id)
  • Wait Event Property: set in the Wait Until event (e.g., survey_type)
Wait Until Event Example
{
  "events": [
    {
      "external_id": "UserA",
      "name": "survey_complete",
      "payload": {
          "survey_type": "survey_1"
      }
    }
  ]
}
When the value of survey_id matches the value of survey_type, that instance of the user will progress through the Journey.
You can use the same properties (e.g., survey_id) in both the Trigger Event Property and the Wait Event Property. The example uses different properties (e.g., survey_id and survey_type) to demonstrate the concept.Properties are case-sensitive! survey_1 does not equal Survey_1.
Expiration branch:If the Wait Until event does not occur within the expiration time, the user will progress through the Journey. This example gives the user 1 week to complete the survey.

Wait Until step using a custom event

3

Add a message step

To complete the example, add a message step within the Expiration branch to send the reminder.

Message step within the Expiration branch

4

Test it out!

After following the steps above, you can test it:
  • Replace the external_id in the Custom Event API with your external ID
  • Trigger the survey_start event with a survey_id of survey_1
    • You will see your user enter the Journey and flow into the Wait Until step
Events are not immediate but very quick! You may need to wait a few minutes before the event is processed.Check the Custom Events list to see if the event was processed.
  • Trigger another survey_start event with a survey_id of survey_2
    • You will see 2 users enter the Journey and Wait Until step
  • Trigger the survey_complete event with a survey_type of survey_1
    • You will see your user progress through the Journey
  • Trigger another survey_complete event with a survey_type of survey_2
    • You will see both instances of your user progress through the Journey and exit
You completed the Journey custom event example with Event Matching!

​
Time Window

Restrict when users can move to the next step in the Journey based on specific days and times. Example: Only allow users to receive a message on weekends in the evening.

Screenshot showing an example of a time window node

​
How time window behavior works

If a user enters this node outside the allowed time:
  • OneSignal sets a timer to delay the user until the next available window
  • The entry time into the window is randomized
Example: If your time window is Tuesdays from 1:00 PM to 6:00 PM PST, and a user hits the node on Monday, they may continue Tuesday at a random time like 5:45 PM.

​
Yes/No branch

Branch users based on segment membership or message behavior.

​
Segment membership

Create branches based on what segment a user is in. Example: If users are tagged by plan type:
  • “Free” branch = promote upgrade
  • “Paid” branch = highlight premium features

​
Message behavior

Branch based on interaction with previous messages in the Journey:
  • Push: Clicked, Delivered
  • Email: Clicked, Opened, Delivered
Note: Safari does not support Confirmed Delivery.

​
Split Branch

Randomly distribute users across different paths to test messaging, channels, or Journey flows.

An example of a 3-way split branch

Once a Journey is live, you cannot edit a Split Branch. To change the number of branches, create a new Journey.

​
How it works

  • Up to 20 branches
  • Set equal or custom percentage splits
  • Percentages round to whole numbers (e.g., 3-way split becomes 34/33/33)
  • Distribution may vary slightly with small sample sizes

Split branch settings

By default, users are re-randomized each time they re-enter a Journey. To keep them on the same branch, turn off Randomize on re-entry. Use the Tag User action to track which branch a user followed.

​
ABN Tests (Multivariate Testing)

Nest Split Branches to simulate more complex testing structures. Example: To split users equally across 3 variants:
  1. First branch: 33% vs 67%
  2. Under the 67% branch, add another 50/50 Split Branch
This gives ~33% on each path.

​
Control Groups

Test the impact of messaging by leaving one branch empty (no message nodes).

​
Choosing a winner

Once a winning variant is identified, update the branch to send 100% of traffic down that path.

​
Tag User

Use this action to apply or remove tags during a Journey. Common use cases:
  • Track Journey progress (e.g., journeyStep: welcome)
  • Power in-app messages by tagging users at key moments
  • Exclude users from other Journeys using active tags

A simple onboarding/welcome flow

​
Example: onboarding flow control

  1. First step: Add a tag (e.g., onboardingJourney: active)
  2. Use this tag to create a segment for exclusion from other Journeys
  3. Last step: Remove the tag by setting the value to blank

A tag node settings to remove the tag from the user