Tile Types
The journey canvas uses eight tile types to define the steps customers move through. Each tile has a specific purpose, configuration options, and connection rules.
Entry
The Entry tile defines how customers enter the journey. Every journey must have exactly one Entry tile, and it must be the starting point of the canvas (no incoming connections).
Configuration
| Field | Description | Required |
|---|---|---|
| Entry type | How customers enter: audience, event, or manual | Yes |
| Audience | The audience whose members enter the journey (for audience entry) | Conditional |
| Event name | The event that triggers entry (for event entry) | Conditional |
| Event filters | Property-level conditions on the triggering event | No |
| Include existing | Whether current audience members enter immediately or only new joiners | No |
Entry Types
Audience Entry
Customers enter when they become members of the specified audience. This is evaluated each time the audience is recomputed.
- Include existing members — When enabled, all current audience members enter when the journey is activated. When disabled, only customers who join the audience after activation enter.
- Re-entry — By default, a customer enters only once. Enable re-entry in journey settings to allow customers who leave and rejoin the audience to enter again.
Event Entry
Customers enter when they perform a specific event. Each event occurrence can trigger a separate entry.
- Event name — Must match an event name from your Events configuration (e.g.,
cart_abandoned,signed_up) - Event filters — Optional property conditions (e.g.,
cart_value > 50,plan = "enterprise")
Manual Entry
Customers are added explicitly through the UI or API. No automatic triggers.
- Use the Add Members button in the journey detail view to upload customer IDs
- Or use the API:
POST /api/v1/journeys/{id}/members
Connection Rules
- No incoming connections allowed
- Exactly one outgoing connection (to the first step)
Wait
The Wait tile pauses a customer at that point in the journey for a specified duration or until a condition is met.
Configuration
| Field | Description | Required |
|---|---|---|
| Wait type | duration or condition | Yes |
| Duration | Fixed time to wait (for duration type) | Conditional |
| Duration unit | Minutes, hours, or days | Conditional |
| Condition | Event or trait condition to wait for (for condition type) | Conditional |
| Timeout | Maximum time to wait for a condition before proceeding | No |
Wait Types
Duration Wait
Pause for a fixed amount of time. The customer proceeds after the duration elapses.
Examples:
- Wait 1 hour after cart abandonment before sending a reminder
- Wait 3 days after onboarding email before checking engagement
- Wait 30 minutes to let a real-time event propagate through the system
Duration waits respect quiet hours if configured in journey settings. If a duration expires during quiet hours, the customer proceeds when quiet hours end.
Condition Wait
Pause until a customer meets a specific condition. The customer proceeds as soon as the condition is satisfied, or when the timeout expires.
Condition types:
- Event received — Wait until the customer performs a specific event (e.g.,
email_opened,purchase_completed) - Trait changes — Wait until a trait value matches a condition (e.g.,
engagement_score > 80) - Audience membership — Wait until the customer joins or leaves a specific audience
The timeout is critical for condition waits — it defines the maximum time to wait. If the condition is not met within the timeout, the customer proceeds to the next tile along the default path.
Connection Rules
- One incoming connection
- One outgoing connection (for duration waits)
- Two outgoing connections for condition waits: one for “condition met” and one for “timed out”
Branch
The Branch tile splits the journey into multiple paths based on conditions, percentages, or randomization. See Branching for a deep dive.
Configuration
| Field | Description | Required |
|---|---|---|
| Branch type | condition, percentage, or random | Yes |
| Conditions | One or more trait/event/audience conditions (for condition branches) | Conditional |
| Percentages | Percentage allocation per branch (for percentage splits) | Conditional |
| Branch count | Number of random branches (for random splits) | Conditional |
Branch Types
Condition Branch
Evaluate one or more conditions and route the customer to the first matching branch. Includes an else branch for customers who match no conditions.
Example:
- Branch 1:
lifetime_value > 500— route to VIP path - Branch 2:
lifetime_value > 100— route to standard path - Else: route to nurture path
Conditions are evaluated top-to-bottom. The customer takes the first branch whose condition is true.
Percentage Split
Divide customers randomly into groups by percentage. Useful for A/B testing.
Example:
- Branch A (80%) — Send the new email template
- Branch B (20%) — Send the control email
Percentages must sum to 100%. The split is deterministic per customer ID, so the same customer always takes the same branch if they re-enter.
Random Branch
Divide customers evenly across N branches without specifying percentages. Equivalent to a percentage split with equal allocations.
Connection Rules
- One incoming connection
- Multiple outgoing connections (one per branch, including else/default)
- At least two outgoing connections required
Action
The Action tile sends data to a destination. This is how journeys activate — by pushing customers to email platforms, ad networks, CRMs, webhooks, and more.
Configuration
| Field | Description | Required |
|---|---|---|
| Destination | The destination to send to | Yes |
| Action type | Depends on destination (e.g., send email, add to list, create record) | Yes |
| Field mapping | Map customer traits/attributes to destination fields | Yes |
| Template | Message template or campaign ID (for messaging destinations) | Depends on destination |
Destination Actions
Each destination type supports different actions:
| Destination Type | Available Actions |
|---|---|
| Email (Braze, SendGrid, etc.) | Send email, add to campaign, update subscription |
| SMS (Twilio, etc.) | Send SMS, send MMS |
| Push (OneSignal, etc.) | Send push notification |
| Ad platforms (Google, Meta, etc.) | Add to custom audience, remove from audience |
| CRM (Salesforce, HubSpot, etc.) | Create/update contact, create task, log activity |
| Webhook | POST, PUT, or PATCH to a URL |
Field Mapping
Map customer data to the fields the destination expects. You can map:
- Traits — Computed customer attributes (e.g.,
lifetime_value,plan_name) - Entity attributes — Raw attributes from the schema (e.g.,
email,first_name) - Static values — Fixed strings or numbers (e.g.,
source = "journey") - Journey context — Journey-specific variables (e.g.,
journey_name,step_name,entry_date)
Error Handling
If an action fails (destination unreachable, invalid data, rate limit), the behavior depends on the configured retry policy:
| Policy | Behavior |
|---|---|
| Retry (default) | Retry up to 3 times with exponential backoff. If all retries fail, mark the action as failed and proceed. |
| Skip | Mark as failed and immediately proceed to the next tile. |
| Block | Hold the customer at this tile until the action succeeds (manual intervention may be needed). |
Connection Rules
- One incoming connection
- One outgoing connection
Update Profile
The Update Profile tile modifies trait values on the customer’s profile. This is useful for tracking journey progress, setting flags, or adjusting scores.
Configuration
| Field | Description | Required |
|---|---|---|
| Updates | One or more trait-value pairs to set | Yes |
Update Operations
| Operation | Description | Example |
|---|---|---|
| Set | Set a trait to a fixed value | onboarding_stage = "email_sent" |
| Increment | Add a number to the current value | journey_touchpoints += 1 |
| Append | Add a value to an array trait | journey_tags[] += "onboarding" |
| Clear | Remove the trait value | temp_discount_code = null |
Profile updates take effect immediately and are visible to subsequent tiles, other journeys, audiences, and syncs.
Connection Rules
- One incoming connection
- One outgoing connection
Webhook
The Webhook tile calls an external HTTP endpoint, allowing integration with any system that has an API.
Configuration
| Field | Description | Required |
|---|---|---|
| URL | The endpoint to call | Yes |
| Method | HTTP method: POST, PUT, PATCH, GET, or DELETE | Yes |
| Headers | Custom HTTP headers (e.g., Authorization, Content-Type) | No |
| Body template | JSON body with variable interpolation | No |
| Timeout | Request timeout in seconds (default: 30) | No |
| Retry policy | How to handle failures (retry, skip, block) | No |
Body Template
The body supports variable interpolation using double curly braces:
{
"customer_id": "{{customer_id}}",
"email": "{{email}}",
"journey": "{{journey_name}}",
"step": "{{step_name}}",
"lifetime_value": {{lifetime_value}},
"triggered_at": "{{timestamp}}"
}Available variables include all customer traits, entity attributes, and journey context variables.
Response Handling
The webhook response can optionally feed data back into the journey:
- Status code — Used to determine success (2xx) or failure (4xx/5xx)
- Response body — Can be parsed and stored as a temporary journey variable for use in subsequent branch conditions
Connection Rules
- One incoming connection
- One outgoing connection
Sub-Journey
The Sub-Journey tile transfers a customer into another journey. This enables modular journey design where common sequences are extracted into reusable sub-journeys.
Configuration
| Field | Description | Required |
|---|---|---|
| Target journey | The journey to transfer the customer into | Yes |
| Wait for completion | Whether to block until the sub-journey completes | No |
Behavior
- If wait for completion is enabled, the customer pauses at this tile until they exit the sub-journey, then proceeds to the next tile
- If wait for completion is disabled, the customer immediately proceeds to the next tile while also entering the sub-journey concurrently
The target journey must be in Active state. If it’s paused or in draft, the sub-journey tile behaves as a pass-through.
Sub-journeys can be nested, but circular references are not allowed (journey A cannot directly or indirectly reference itself).
Connection Rules
- One incoming connection
- One outgoing connection
Exit
The Exit tile removes the customer from the journey. Every journey must have at least one Exit tile.
Configuration
| Field | Description | Required |
|---|---|---|
| Exit label | A descriptive label for analytics (e.g., “Converted”, “Timed Out”, “Unsubscribed”) | No |
Behavior
When a customer reaches an Exit tile:
- They are removed from the journey’s active members
- Their journey completion is recorded with the exit label and timestamp
- They become eligible for re-entry (if re-entry is enabled in journey settings)
Multiple Exit tiles are common in journeys with branches — each branch path typically ends with its own Exit tile, each labeled differently for analytics purposes. This lets you see how many customers completed via conversion versus timeout versus unsubscription.
Connection Rules
- One or more incoming connections
- No outgoing connections allowed